VyOS command definitions, scripts, and utilities (mirror of https://github.com/vyos/vyos-1x.git) https://git.amelek.net/vyos/vyos-1x.git/atom?h=T6732-reusable-build-package 2024-09-10T06:56:18+00:00 2024-09-10T06:56:18+00:00 Nicolás Fort 95703796+nicolas-fort@users.noreply.github.com 2024-09-10T06:56:18+00:00 urn:sha1:ec3ebe8890c60bbb6f657335c212ac7078dc731c 2024-08-28T12:19:19+00:00 Nicolas Fort nicolasfort1988@gmail.com 2024-08-26T18:10:01+00:00 urn:sha1:8e0e1a99e5510c7575ab8a09145d6b4354692d55 2024-08-05T05:44:29+00:00 Christian Breunig christian@breunig.cc 2024-08-05T05:44:29+00:00 urn:sha1:6e910723ed9bd7f510f39379298bd98375608bfa 2024-08-04T07:52:57+00:00 Andrew Topp andrewt@telekinetica.net 2024-08-04T07:52:57+00:00 urn: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 2024-08-02T12:50:26+00:00 Nicolas Fort nicolasfort1988@gmail.com 2024-07-31T12:42:25+00:00 urn:sha1:c33cd6157ebc5c08dc1e3ff1aa36f2d2fbb9ca83 2024-08-01T16:25:39+00:00 Nicolas Fort nicolasfort1988@gmail.com 2024-07-24T17:40:28+00:00 urn:sha1:a8a9cfe750da719605ab90ce8c83c42276ab07f3 2024-08-01T16:25:31+00:00 Nicolas Fort nicolasfort1988@gmail.com 2024-07-24T14:08:19+00:00 urn:sha1:20551379e8e2b4b6e342b39ea67738876e559bbf 2024-07-28T11:47:07+00:00 talmakion andrewt@telekinetica.net 2024-07-28T11:47:07+00:00 urn:sha1:e2bf8812f73a75356f56274968be8859a2186d73 * Change ipsec match-ipsec/none to match-ipsec-in and match-none-in for fw rules * Add ipsec match-ipsec-out and match-none-out * Change all the points where the match-ipsec.xml.i include was used before, making sure the new includes (match-ipsec-in/out.xml.i) are used appropriately. There were a handful of spots where match-ipsec.xml.i had snuck back in for output hooked chains already (the common-rule-* includes) * Add the -out generators to rendered templates * Heavy modification to firewall config validators: * I needed to check for ipsec-in matches no matter how deeply nested under an output-hook chain(via jump-target) - this always generates an error. * Ended up retrofitting the jump-targets validator from root chains and for named custom chains. It checks for recursive loops and improper IPsec matches. * Added "test_ipsec_metadata_match" and "test_cyclic_jump_validation" smoketests 2024-06-04T13:22:24+00:00 Nicolas Fort nicolasfort1988@gmail.com 2024-05-24T16:44:41+00:00 urn:sha1:770edf016838523c248e3c8a36c5f327a0b98415 2024-05-15T17:09:16+00:00 Nicolas Fort nicolasfort1988@gmail.com 2024-05-15T17:09:16+00:00 urn:sha1:6871c5541c1962e63d7a9b75d2bb43df2a8d372b