<feed xmlns='http://www.w3.org/2005/Atom'>
<title>vyos-1x.git/interface-definitions/include/firewall/gre.xml.i, branch rolling</title>
<subtitle>VyOS command definitions, scripts, and utilities (mirror of https://github.com/vyos/vyos-1x.git)
</subtitle>
<id>https://git.amelek.net/vyos/vyos-1x.git/atom?h=rolling</id>
<link rel='self' href='https://git.amelek.net/vyos/vyos-1x.git/atom?h=rolling'/>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/vyos-1x.git/'/>
<updated>2024-08-05T05:44:29+00:00</updated>
<entry>
<title>firewall: T4694: fix GRE key include path in XML</title>
<updated>2024-08-05T05:44:29+00:00</updated>
<author>
<name>Christian Breunig</name>
<email>christian@breunig.cc</email>
</author>
<published>2024-08-05T05:44:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/vyos-1x.git/commit/?id=6e910723ed9bd7f510f39379298bd98375608bfa'/>
<id>urn:sha1:6e910723ed9bd7f510f39379298bd98375608bfa</id>
<content type='text'>
</content>
</entry>
<entry>
<title>firewall: T4694: Adding GRE flags &amp; fields matches to firewall rules</title>
<updated>2024-08-04T07:52:57+00:00</updated>
<author>
<name>Andrew Topp</name>
<email>andrewt@telekinetica.net</email>
</author>
<published>2024-08-04T07:52:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/vyos-1x.git/commit/?id=60b0614296874c144665417130d4881461114db0'/>
<id>urn:sha1:60b0614296874c144665417130d4881461114db0</id>
<content type='text'>
* Only matching flags and fields used by modern RFC2890 "extended GRE" -
  this is backwards-compatible, but does not match all possible flags.
* There are no nftables helpers for the GRE key field, which is critical
  to match individual tunnel sessions (more detail in the forum post)
  * nft expression syntax is not flexible enough for multiple field
    matches in a single rule and the key offset changes depending on flags.
  * Thus, clumsy compromise in requiring an explicit match on the "checksum"
    flag if a key is present, so we know where key will be. In most cases,
    nobody uses the checksum, but assuming it to be off or automatically
    adding a "not checksum" match unless told otherwise would be confusing
  * The automatic "flags key" check when specifying a key doesn't have similar
    validation, I added it first and it makes sense. I would still like
    to find a workaround to the "checksum" offset problem.
  * If we could add 2 rules from 1 config definition, we could match
    both cases with appropriate offsets, but this would break existing
    FW generation logic, logging, etc.
* Added a "test_gre_match" smoketest
</content>
</entry>
</feed>
