vyos-1x.git/interface-definitions, branch current-merge-commit-handlingVyOS command definitions, scripts, and utilities (mirror of https://github.com/vyos/vyos-1x.git)
https://git.amelek.net/vyos/vyos-1x.git/atom?h=current-merge-commit-handling2024-08-05T05:44:29+00:00firewall: T4694: fix GRE key include path in XML2024-08-05T05:44:29+00:00Christian Breunigchristian@breunig.cc2024-08-05T05:44:29+00:00urn:sha1:6e910723ed9bd7f510f39379298bd98375608bfaMerge branch 'current' into feature/T4694/gre-match-fields2024-08-05T05:28:27+00:00Christian Breunigchristian@breunig.cc2024-08-05T05:28:27+00:00urn:sha1:d30646fad07bd9263b385aa6a26c6d6dbc163e27Merge pull request #3920 from fett0/T65552024-08-05T05:26:17+00:00Christian Breunigchristian@breunig.cc2024-08-05T05:26:17+00:00urn:sha1:aa842a640cbe96719caf4cd1843d718a68f81319
OPENVPN: T6555: add server-bridge options in mode serverfirewall: T4694: Adding GRE flags & fields matches to firewall rules2024-08-04T07:52:57+00:00Andrew Toppandrewt@telekinetica.net2024-08-04T07:52:57+00:00urn:sha1:60b0614296874c144665417130d4881461114db0
* 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
OPENVPN: T6555: fix name to bridge2024-08-02T14:10:51+00:00fett0fernando.gmaidana@gmail.com2024-08-02T14:10:51+00:00urn:sha1:d5ae708581d453e2205ad4cf8576503f42e262b6T4072: change same helpers in xml definitions; add notrack action for prerouting chain; re introduce <set vrf> in policy; change global options for passing traffic to IPvX firewall; update smoketest2024-08-02T12:50:26+00:00Nicolas Fortnicolasfort1988@gmail.com2024-07-31T12:42:25+00:00urn:sha1:c33cd6157ebc5c08dc1e3ff1aa36f2d2fbb9ca83T6570: firewall: add global-option to configure sysctl parameter for enabling/disabling sending traffic from bridge layer to ipvX layer2024-08-01T16:25:39+00:00Nicolas Fortnicolasfort1988@gmail.com2024-07-24T17:40:28+00:00urn:sha1:a8a9cfe750da719605ab90ce8c83c42276ab07f3T4072: firewall: extend firewall bridge capabilities, in order to include new chains, priorities, and firewall groups2024-08-01T16:25:31+00:00Nicolas Fortnicolasfort1988@gmail.com2024-07-24T14:08:19+00:00urn:sha1:20551379e8e2b4b6e342b39ea67738876e559bbfMerge pull request #3221 from lucasec/t58732024-08-01T11:08:36+00:00Christian Breunigchristian@breunig.cc2024-08-01T11:08:36+00:00urn:sha1:962ead698e191ff413aaa1585270dfed48100547
T5873: ipsec remote access VPN: support VTI interfaces.OPENVPN: T6555: add server-bridge options in mode server2024-07-31T18:21:25+00:00fett0fernando.gmaidana@gmail.com2024-07-31T18:21:25+00:00urn:sha1:4acad3eb8d9be173b76fecafc32b0c70eae9b192