1
23.7 Legacy Series / VTI Route VPNs - Filtering
« on: October 11, 2023, 04:10:03 am »
Been learning IPSEC VTI route tunnels and Opnsense config. Need to migrate from legacy.
Having been accustomed to policy VPNs I’ve always filtered the ipsec at source. Specific tunnels / hosts terminated. But seems the route vpn standard is no filter and all 0.0.0.0/0 is processed.
So then all lans pass traffic for every ipsec# gateway route.
So effectively, the only way to control traffic is with IPSEC# INT outbound rules. And subsequent inbound rules at destination firewall on global ipsec interface.
I’ve read on the praises of routed based VPNs as there is no filter rules required. But my understanding is it is just trading places. Rather than define them on ipsec filter rules, I’m applying same rules to IPSEC# INT outbound rules. (I don’t want everything allowed at source and only block at destination inbound)
So I explored the tunables
net.inet.ipsec.filtertunnel = 1
net.inet6.ipsec6.filtertunnel = 1
net.enc.in.ipsec_filter_mask = 0
net.enc.out.ipsec_filter_mask = 0
https://docs.opnsense.org/manual/vpnet.html#route-based-vti
The filtering appears to work but one cannot define multiple source / destination in same phase2. Each needs its own phase2 / child.
The other benefit I see is if “install polices” accidentally gets enabled with 0.0.0.0/0 it will totally lock you out until console access + service strongswan stop. I don’t believe this can happen now if_ipsec(4) filtering enabled? I want to test this more with filtering enabled as I find the ability to totally break firewall access with a simple “install policy” toggle to be a bit concerning.
So - are there any drawbacks to filtering VTIs (if_ipsec(4)?
(Other than that policy VPNs can no longer be used)
Thank you.
Edit
Actually now noticing different behavior with tunables if_ipsec(4) filtering enabled. Traffic on destination firewall now appears to be flowing inbound to VTI IPSEC# interface rather than inbound via global IPSEC interface. I'm guessing this by design?
I'm mistaken. (if_ipsec(4) does not appear to be working.
If I disable a Phase 2 with defined local / remote subnets traffic still flows?
So my other phase 2 which also has local / remote subnets defined must not be actually using them and is still using 0.0.0.0/0
No idea WTF is happening here. Other than policy vpn is simpler.
Having been accustomed to policy VPNs I’ve always filtered the ipsec at source. Specific tunnels / hosts terminated. But seems the route vpn standard is no filter and all 0.0.0.0/0 is processed.
So then all lans pass traffic for every ipsec# gateway route.
So effectively, the only way to control traffic is with IPSEC# INT outbound rules. And subsequent inbound rules at destination firewall on global ipsec interface.
I’ve read on the praises of routed based VPNs as there is no filter rules required. But my understanding is it is just trading places. Rather than define them on ipsec filter rules, I’m applying same rules to IPSEC# INT outbound rules. (I don’t want everything allowed at source and only block at destination inbound)
So I explored the tunables
net.inet.ipsec.filtertunnel = 1
net.inet6.ipsec6.filtertunnel = 1
net.enc.in.ipsec_filter_mask = 0
net.enc.out.ipsec_filter_mask = 0
https://docs.opnsense.org/manual/vpnet.html#route-based-vti
The filtering appears to work but one cannot define multiple source / destination in same phase2. Each needs its own phase2 / child.
The other benefit I see is if “install polices” accidentally gets enabled with 0.0.0.0/0 it will totally lock you out until console access + service strongswan stop. I don’t believe this can happen now if_ipsec(4) filtering enabled? I want to test this more with filtering enabled as I find the ability to totally break firewall access with a simple “install policy” toggle to be a bit concerning.
So - are there any drawbacks to filtering VTIs (if_ipsec(4)?
(Other than that policy VPNs can no longer be used)
Thank you.
Edit
Actually now noticing different behavior with tunables if_ipsec(4) filtering enabled. Traffic on destination firewall now appears to be flowing inbound to VTI IPSEC# interface rather than inbound via global IPSEC interface. I'm guessing this by design?
I'm mistaken. (if_ipsec(4) does not appear to be working.
If I disable a Phase 2 with defined local / remote subnets traffic still flows?
So my other phase 2 which also has local / remote subnets defined must not be actually using them and is still using 0.0.0.0/0
No idea WTF is happening here. Other than policy vpn is simpler.