Legacy IPSEC vti routed firewall interface vs ipsec interface

[markes20754]

Hi All,
I'm transitioning from PFSense to OPNSense and am trying to get clarification on the use of the Routed VTI firewall interface vs the IPsec interface rules.

In PFSense, when you create a routed VTI IPSec tunnel, you don't see an interface in the firewall to apply rules to -- all rules (for all tunnels) are applied to the IPSec interface. In OPNSense I see an interface for all of my VTI Routed IPSec tunnels in addition to the IPSec interface.

From what I can tell, the OPNSense IPSEC firewall rule logic is the same as PFSense where rules should be applied to the IPSec interface but when I did some testing and applied an ANY/ANY rule with logging to one of the VTI firewall interfaces, I see allowed traffic.

My question is this: Are the IPSec VTI Routed interfaces used at all with respect to firewall rules? If so, when should a rule be created using the tunnel's VTI interface vs the IPSec interface? The documentation isn't clear.

Thank you!
Mark

[AdSchellevis]

Hi Mark,

By default traffic is (only) filtered on enc0, but when only using VTI tunnels, it's also possible to filter on these interfaces as described in the notes here https://docs.opnsense.org/manual/vpnet.html#route-based-vti

Best regards,

Ad

[markes20754]

Ok I think I got it. Confirming:
By default, the VTI interfaces - ipsec(X) aren't used and all rules should be added to the IPSec (enc0) interface. In short, this is the same as pfSense.

However, if I want to build rules per-VTI interface I would set net.inet.ipsec.filtertunnel and net.inet6.ipsec6.filtertunnel = 1 AND net.enc.in.ipsec_filter_mask and net.enc.out.ipsec_filter_mask = 0

I'm not using any policy based tunnels, so it sounds like there's no downside to this change. Other than making rule organization a little easier is there any pro/con to the "per interface rule" approach vs using enc0?

What about client to firewall IPSec tunnels (I think they're called Road warrior in the documentation)?

Thanks!

[Monviech (Cedrik)]

Hey, here is also a more verbose explanation I wrote a while ago about the differences between the enc and ipsec interfaces:

enc(4) is a virtual IPsec interface that is used to pass raw IP packets before encapsulation, and after decapsulation of ESP. That means, that the packets can be filtered and nated on it, before they're processed by IPsec. That is also the reason, why you need to set manual SPD (Security Policy Database) entries, when you NAT. Because you NAT before IPsec encapsulates the ESP packet. And if there's no security policy for the source IP address, IPsec will drop the packet before its encapsulated.

ipsec(4) is a virtual tunnel interface, that is used to pass already encapsulated packets. That means, you can't filter and NAT them, because the original IP header was already encapsulated into an ESP packet.

Now, that should mean, that you should be able to filter and nat all packets that come in and out of enc(4), because they all have their original IP header and are raw packets. In practice, this somehow does not work if "ipsec" is also introduced. With VTI, the packets first go into enc(4), and after they have been encapsulated they go into ipsec(4). Something about this process makes filter and NAT impossible, due to an implementation bug.

With the tunable "net.inet.ipsec.filtertunnel" you can change the filter behavior. Per default, you can perform packet filtering and NAT before and after ESP on the enc(4) interface. With the tunable set, you can filter "inside" the ESP packet, but because enc(4) doesn't have any encapsulated packets, the filter won't work on it anymore. It will then work on the ipsec(4) interface where the encapsulated ESP packets are. The filter is set on the IP header inside the ESP packets.

Because Policy Based tunnel traffic only passes through the enc(4) interface, and not also through an ipsec(4) interface like VTI tunnels, you can either filter on the RAW IP packets, or on the ESP packets, but not on both (at least in FreeBSDs ipsec(4) and enc(4) implementation)

EDIT:
Roadwarriors will always use the enc0 interface and policy based tunnels.