Why does the tunable "net.inet.ipsec.filtertunnel" change the pf filter/nat behavior of other virtual tunnel interfaces? (Like GRE)

[Monviech]

Hello, I'm new here

I want to get to the bottom of some behavior regarding FreeBSD and the pf firewall implementation in it.

I have read the community guidelines regarding derivatives.

GhostBSD, pfSense, TrueNAS, and all other FreeBSD Derivatives

Questions about 'derivative FreeBSDs', like GhostBSD TrueNAS XigmaNAS OPNsense pfSense BSD Router Project NomadBSD helloSystem HardenedBSD should be asked on the forums and/or mailing lists for these specific products. See below for links. If you still think your questions should be asked...

forums.freebsd.org

I'm coming from the derivative OPNsense, and already posted about the behavior in their forum with an in depth analysis. The post there has all the info about test setup, all the pfctl outputs about filter rules, nat rules, states, and packet captures, as well as conclusions.

SNAT and Virtual Tunnel Interfaces - An in depth analysis

SNAT and Virtual Tunnel Interfaces - An in depth analysis

forum.opnsense.org

If I should replicate any of those tests with two FreeBSD systems without the derivative OPNsense on it, I'm willing to do so.

I know about this bug with pf:

248474 – if_ipsec: NAT broken on IPsec/VTI

bugs.freebsd.org

I have analyzed the behavior of PF SNAT on a virtual tunnel interface. I came to the conclusion that changing these kernel runtime tunables, doesn't only make SNATing and packet filtering on if_ipsecXX work, but also on if_greXX, if_vxlanXX and if_gifXX virtual tunnel interfaces.

net.enc.in.ipsec_filter_mask = 0
net.enc.out.ipsec_filter_mask = 0
net.inet.ipsec.filtertunnel = 1
net.inet6.ipsec6.filtertunnel = 1

Changing the tunables back to if_encXX, breaks SNAT and packet filtering on if_greXX, if_vxlanXX, if_gifXX and if_ipsecXX.

net.enc.in.ipsec_filter_mask = 1
net.enc.out.ipsec_filter_mask = 1
net.inet.ipsec.filtertunnel = 0
net.inet6.ipsec6.filtertunnel = 0

I would really like to know if that's a known side effect or something unintended. Should I open a bug report? So far, these tunables seem to affect how all virtual tunnel interfaces work, and not only IPsec. (With exception to wireguard and openvpn).

Thank you for your community time and have a great day,
Monviech

EDIT: I've just noticed that I posted this in the wrong forum. I'm sorry. It should have been in Firewalls due to PF.

 

[SirDice]

I've just noticed that I posted this in the wrong forum. I'm sorry. It should have been in Firewalls due to PF.

No worries, thread moved. Next time simply report your own post, then a mod gets notified and will move the thread accordingly.

 

[Monviech]

I have probably found a correlating case. It has to do with introducing enc0 to an l2tp connection with pf, and that breaks the behavior of rdr.

pf rdr statement & ipsec processing interaction

freebsd-net.freebsd.narkive.com

That probably means my finding is related (and its an old story). As long as enc0 is filtered by PF and there is something like gre or l2tp passed through the policy based tunnel, nat and rdr are problematic.

If you enable the tunables and send gre through a VTI IPsec interface, things like NAT and RDR seems to work as expected.