OPNsense Forum
English Forums => 23.7 Legacy Series => Topic started by: ThyOnlySandman 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.
-
Maybe these links help you understand more of the behavior:
https://forum.opnsense.org/index.php?topic=36254.0
https://forum.opnsense.org/index.php?topic=36319.0
It's not that easy to understand and the tunables change more than just ipsec.
-
Thanks for help and links.
Agreed - not that easy to understand. I need to re-read more understand the SNAT. I do not believe NAT has been an issue in my test lab.
I really like Opnsense and am grateful for it. But the devs should really consider a VPN wizard tool that takes one through a linear step 1,2,3. Its kinda wild a VPN config covers so many different sections of config. I count 8 different pages / sections.
Reading through your posts its my understand that by enabling these tunables the phase 2 local / remote address filtering should be working.
In my lab which very simliar of yours in these post I have two phase 2s.
Phase 2 - A
Local: 10.99.99.0/24
Remote: 100.20.20.0/24
Phase 2 - B
Local: 172.16.1.1/32
Remote: 172.16.2.1/32
What I don't understand is why when I disable Phase 2 - B. VPN Traffic still flows for 172.16.1.1 or 172.16.2.1
Its seems that despite Phase 2 A having defined subnets its still using 0.0.0.0/0 and all traffic is being processed by ipsec kernel.
I thought that enabling the ipsec filtering tunables that I could achieve ipsec filtering just like policy vpns and define the subnets within the phase2?
-
net.enc.in.ipsec_filter_mask = 0
net.enc.out.ipsec_filter_mask = 0
net.inet.ipsec.filtertunnel = 1
net.inet6.ipsec6.filtertunnel = 1
= Enable Packet Filtering and NAT on if_ipsec, if_gre, if_vxlan and if_gif
= Disable Packet Filtering and NAT on if_enc0 (Shown as IPsec in the GUI)
This is the mode that makes VTI IPsec (and more) filtered, but makes policy based IPsec unfiltered.
net.enc.in.ipsec_filter_mask = 1
net.enc.out.ipsec_filter_mask = 1
net.inet.ipsec.filtertunnel = 0
net.inet6.ipsec6.filtertunnel = 0
= Disable Packet Filtering and NAT on if_ipsec, if_gre, if_vxlan and if_gif
= Enable Packet Filtering and NAT on if_enc0 (Shown as IPsec in the GUI)
This mode makes policy based IPsec filtered, but VTI IPsec unfiltered.
-
net.enc.in.ipsec_filter_mask = 0
net.enc.out.ipsec_filter_mask = 0
net.inet.ipsec.filtertunnel = 1
net.inet6.ipsec6.filtertunnel = 1
= Enable Packet Filtering and NAT on if_ipsec, if_gre, if_vxlan and if_gif
= Disable Packet Filtering and NAT on if_enc0 (Shown as IPsec in the GUI)
This is the mode that makes VTI IPsec (and more) filtered, but makes policy based IPsec unfiltered.
Yes this is exactly what I have set on both firewalls yet having behavior mentioned on previous post where IPSEC VTI filtering does not appear to be working.
After enabling these tunables the difference I see that inbound traffic on a destination firewall comes in via IPSEC# VTI INT rather than the traditional IPSEC INT.
But if IPSEC filtering was working then by disabling my phase 2 - b, traffic should not flow for 172.16.1.1 or 172.16.2.1 yet it still does.
-
Disable filtering means the traffic is unfiltered. It's not blocked, everything is allowed through.
The policy based traffic will always match on enc0 (IPsec), I think.
For the filtering on the VTI interfaces it seems to be important that the REQID of the VTI interface and the REQID of the Phase 2 Child match.
But you might be onto something there. Its actually a great idea to try policy vpns with the vti interfaces and reqids set. I definitely going to try this in a test setup soon.
-
I considered that last night and made that change. And just confirmed again its set. And confirmed no typos in tunables.
Both firewalls IPSEC1 VTI (REQID=1)
Both firewalls have each phase 2 defined as REQID = 1
Still doesn't appear VTI filtering is working.
Since the phase 2 - B consists of loopback INT IP on both firewalls I did a swap.
Disabled Phase 2 -A
Enabled Phase 2 - B
Same. Traffic still flows for 10.99.99.0/24 + 10.20.20.0/24 when it shouldn't.
If I disable both 2 phases then all VPN traffic stops. (as it should)
-
I’ll probably just stick with migrating legacy VPN over to new policy VPNs.
But here’s a better layout of config and screenshots
Firewall A
WAN: 10.100.100.200/24
LAN: 10.99.99.254/24
LO: 172.16.1.1/32
IPSEC1: 192.168.200.1/30
Firewall B
WAN: 10.100.100.201/24
LAN: 10.20.20.25/24
LO: 172.16.2.1/32
IPSEC1: 192.168.200.2/30
(https://i.imgur.com/aGAIKRp.jpg)
(https://i.imgur.com/SCRnMbu.jpg)
(https://i.imgur.com/jQB8pVy.jpg)
(https://i.imgur.com/m0HfFDU.jpg)
(https://i.imgur.com/GgPTWrf.jpg)
So you can see status only the one loopback phase 2 is enabled.
A PC off Firewall A LAN with IP 10.99.99.100 pings Firewall B LAN INT IP 10.20.20.25
Its works despite the only phase 2 being enabled on both firewalls is for the loopback tunnel.
And with the traffic now flowing inbound via IPSEC1 VTI rather than IPSEC I believe the tunables for VTI filter are enabled.
Firewall B - live view
(https://i.imgur.com/1EeAlnt.jpg)
-
I didn't have time to test it yet, but I will check it in my test setup when I can.
Though if you have so much evidence already you might be right.
I actually started to replicate what you did but then I didn't understand why you have the loopback interfaces.
The tunnel should be like this for the routing and filtering to work correctly:
Route 10.20.20.0/24 via 192.168.200.2 Route 10.99.99.0/24 via 192.168.200.1
10.99.99.0/24 <------> 192.168.200.1/30 <------> 192.168.200.2/30 <------> 10.20.20.0/24
---------------------------------------------------------
IPsec Tunnel Child: Local 0.0.0.0/0 Remote 0.0.0.0/0
-
I'm just trying a proof of concept of filtering multiple networks or host to host like a policy VPN would work
So the lab just simulating that with the two phase 2s. Only having a single phase 2 up. The ping should not flow for the other phase 2 tunnel networks .99 or .20 network.
I did the same test attempting to limit hosts on single phase 2 tunnel
Local. 10.99.99.254/32
Remote 10.20.20.25/32
So VPN tunnel between Firewall A + Firewall B LAN INT
I then ping from PC off Firewall A LAN - IP 10.99.99.100 to Firewall B LAN INT IP 10.20.20.25. It still works. But Why?
So it appears that even though I have defined subnets in phase 2 it's still using 0.0.0.0.
Edit
Maybe I'm not understanding VTI filtering correctly.
Not sure what command you used to get that routing info but in your example it has:
IPsec Tunnel Child: Local 0.0.0.0/0 Remote 0.0.0.0/0
The way I'm understanding VTI filtering that child should be the defined subnets in the phase 2 and thus filtering on them.
Is that CLI command? I'll run it on mine and see if it also has tunnel child 0.0.0.0/0
-
You are right. In the security policy database all Children without "Policies" checked get 0.0.0.0/0[any] as traffic selector. EDIT: It's actually the VTI creation that sets the Traffic Selector.
VPN: IPsec: Security Policy Database
0.0.0.0/0[any] 0.0.0.0/0[any] 172.16.0.190->172.16.0.189 99e0e1c1-285e-45cd-b4ef-61dcc914c879 2 esp
::/0[any] ::/0[any] 172.16.0.190->172.16.0.189 99e0e1c1-285e-45cd-b4ef-61dcc914c879 2 esp
0.0.0.0/0[any] 0.0.0.0/0[any] 172.16.0.190->172.16.0.189 99e0e1c1-285e-45cd-b4ef-61dcc914c879 3 esp
::/0[any] ::/0[any] 172.16.0.190->172.16.0.189 99e0e1c1-285e-45cd-b4ef-61dcc914c879 3 esp
0.0.0.0/0[any] 0.0.0.0/0[any] 172.16.0.189->172.16.0.190 99e0e1c1-285e-45cd-b4ef-61dcc914c879 2 esp
::/0[any] ::/0[any] 172.16.0.189->172.16.0.190 99e0e1c1-285e-45cd-b4ef-61dcc914c879 2 esp
0.0.0.0/0[any] 0.0.0.0/0[any] 172.16.0.189->172.16.0.190 99e0e1c1-285e-45cd-b4ef-61dcc914c879 3 esp
::/0[any] ::/0[any] 172.16.0.189->172.16.0.190 99e0e1c1-285e-45cd-b4ef-61dcc914c879 3 esp
So it doesn't matter whats in the actual local and remote net in the child when policies is unchecked. I guess it could even be left empty and it didn't matter.
It's the creation of a "Virtual Tunnel Interface" that populates the "Security Policy Database" with the 0.0.0.0/0 Traffic Selectors.
EDIT: As I guessed, you can actually leave "local" and "remote" in the child empty, and the VTI tunnel still works. Doesn't matter whats in it, it's always hard coded as 0.0.0.0/0.
-
Ok, thanks for checking on that.
So - with the tunables enabling VTI filtering and child always being 0.0.0.0 - is this behavior by design (working correctly) or a bug?
Cause essentially the filtering isn't working how I envisioned.
I would still need to control traffic via VTI outbound rules as all LAN traffic behind opnsense would be processed by ipsec kernel.
See I thought by enabling VTI filtering tunables I wouldn't need those VTI outbound rules because only specific phase 2 defined subnets would get forwarded (filtered) to ipsec kernel.
-
I guess the only group of people able to answer that are the developers of 'strongswan' or 'pf'.
I don't know, but it was fun finding out. :)
-
Fair enough. :) - I appreciate your help and attention.