mirror of
https://github.com/jmcorgan/fips.git
synced 2026-10-30 07:37:36 +00:00
Johnathan Corgan
faecddcad4
The gateway how-to said the mesh firewall baseline gates port forwards and that a fips.d drop-in restricts them. It does neither: the gateway rewrites a forwarded connection's destination in prerouting, so the packet takes the forward path, while fips.nft and its drop-ins hook input only. With the baseline loaded, every mesh node that reaches the gateway reaches every port forward. The how-to now says so and gives a restriction that works: a separate table with a forward-hook chain that matches the post-DNAT target address and port, scoped to the mesh interface through its own fips_if define, ending in a drop of other translated connections, loaded alongside the baseline through a fips-firewall.service drop-in. On OpenWrt it points at the packaged zone's src fips rule instead. The mesh firewall how-to and the fips.nft header say port forwards are outside the baseline, and the how-to's TUN rename section says to change the restriction's fips_if too. The gateway troubleshooting step and the host-a-service tutorial no longer describe the input baseline as gating port forwards. Also corrected: the gateway design document attributed the virtual-IP source on replies to the per-mapping SNAT, which only sees the first packet of a new flow sourced from a mapped mesh address; conntrack reversing the DNAT is what does it. It also said port forwards are validated on every config reload, but the gateway has no reload. The configuration reference said the gateway terminates forwarded connections; the kernel translates and forwards them.