IPSEC VTI Tunnels
-
Hello Everyone,
I got vti setup working between pfsense and edgerouter pro with ebgp in place . Patch for 0.0.0.0/0 is required.key point was Address in phase 2 and on edge router firewall allow BGP in VPN zone. VPN configuration on edge router is standard vti setup.
Phase 2
The only one think is that tunnel goes down time to time. In logs I see
Oct 13 08:48:58 php-fpm 35862 /rc.newipsecdns: Gateway, none 'available' for inet6, use the first one configured. ''
Oct 13 08:48:58 php-fpm 35862 /rc.newipsecdns: The command '/sbin/ifconfig 'ipsec3000' create reqid '3000'' returned exit code '1', the output was 'ifconfig: create: bad value'
Oct 13 08:48:57 check_reload_status Reloading filter
Oct 13 08:48:57 php-fpm 35862 /rc.newipsecdns: IPSEC: One or more IPsec tunnel endpoints has changed its IP. Refreshing.
Oct 13 08:48:42 php-fpm 61417 /rc.openvpn: Gateway, none 'available' for inet6, use the first one configured. ''
Oct 13 08:48:41 check_reload_status Reloading filter -
My problem is solved. On the other side (EdgeRouter side) I use Dual-WAN with LB. I'm migrating this tunnel from VyOS to PfSense. The PfSense public IP was being loadbalanced. This caused the IPSec traffic to go over the wrong outside interface. After adding the public IP to the LB Exclude list, things started working.
Now I am running into another (NAT) problem. Maybe one of you can test if you get the same result. If I add an NAT rule to masquerade traffic with IP-address of VTI interface I am not able to reach anything on the EdgeRouter side.
What I am doing to test:
Ping from PfSense CLI to 192.168.111.2 (EdgeRouter). This works without the NAT rule. When I enable the NAT rule it stops working.So far my observations are:
Traffic is leaving IPsec1000 interface on PfSense with correct NAT address (192.168.111.1). Traffic arrives on interface EdgeRouter and EdgeRouter sends traffic back which also arrives back at the IPsec1000 interface. But PfSense never gets reply on ICMP-echo request.NAT rule looks like this. (Interface is VTI interface)
-
I am watching tunnel and it not 100% stable. Sometimes pfsense stop reply to traffic from vpn tunnel. I see traffic arrive on vti interface, but never send reply.
-
@bluray said in IPSEC VTI Tunnels:
Now I am running into another (NAT) problem. Maybe one of you can test if you get the same result. If I add an NAT rule to masquerade traffic with IP-address of VTI interface I am not able to reach anything on the EdgeRouter side.
That's a known issue, NAT doesn't work with VTI currently. There is some weirdness between if_ipsec/VTI and pf where the traffic hits both the ipsecX interface and enc0. You might try putting the NAT rule on the "IPsec" interface in the GUI and not the assigned VTI interface.
-
@jimp said in IPSEC VTI Tunnels:
@bluray said in IPSEC VTI Tunnels:
Now I am running into another (NAT) problem. Maybe one of you can test if you get the same result. If I add an NAT rule to masquerade traffic with IP-address of VTI interface I am not able to reach anything on the EdgeRouter side.
That's a known issue, NAT doesn't work with VTI currently. There is some weirdness between if_ipsec/VTI and pf where the traffic hits both the ipsecX interface and enc0. You might try putting the NAT rule on the "IPsec" interface in the GUI and not the assigned VTI interface.
Hello Jim,
Thank you for your feedback.
Unfortunately that doesn't work in my case. Is there a bugreport for this so I can track this issue? If not how can I make one? -
I don't recall if I made an issue for it on Redmine, but it's not one that we can address. It will need to be taken upstream to FreeBSD directly.
-
I already searched in Redmine, but I couldn't find one. Your explanation explains why there is no. (Due to it being a bug in FreeBSD IPSec implementation which must be fixed by FreeBSD Developers)
I'm not familiair with reporting bugs. Will do some research how to submit one. Hopefully this can be resolved in the future.
-
Bumping this because I'm experiencing a similar problem.
I have 2 IPsec Tunnels to an ISP.
IPSec Phase 1 works good. When Phase 2 would come up for a short period of time, then fail. and the whole tunnel would collapse and restart.
I observed a bunch of logs stating
Nov 19 19:40:41 charon 14[KNL] <con2000|3> querying policy 10.0.255.248/30|/0 === 10.0.255.248/30|/0 in failed, not found Nov 19 19:40:41 charon 14[KNL] <con2000|3> querying policy 10.0.255.248/30|/0 === 10.0.255.248/30|/0 in failed, not found Nov 19 19:40:41 charon 14[KNL] <con2000|3> querying policy 10.0.255.248/30|/0 === 10.0.255.248/30|/0 in failed, not found Nov 19 19:40:41 charon 14[KNL] <con2000|3> querying policy 10.0.255.248/30|/0 === 10.0.255.248/30|/0 in failed, not found
If I had the VTI settings to retain /0 on the remote, that's when my tunnels would constantly fail and restart after about a minute or so. So I executed the PFShell commands above to set /30. After doing so the IPSec/VTI 'appear' stable. But I can see my Security Association Database creating tons of new SPIs. So something still, just isn't right.
I've setup my interfaces, OPT1 and OPT2, but I'm baffled as to why I don't see any Firewall Rule options for OPT1 like I saw in @ScottS post.
I guess I'm curious if I should expect to see OPT1/OPT2 under my firewall rules and further, and further wonder if my accumulation of SPIs is an indication that things aren't quite right.
I can PING
Any help, or insights would be appreciated.
-
I also have a similar issue with the same error message - the tunnel comes up fine, routing is working bi-directionally but if I attempt to do an iperf across the tunnel stops transferring packets almost immediately.
Tried changing the MTU down to 1300, but didn't change anything.I have 2 SG-3100's setup with ikev2 VTI.
$ tracert 192.168.11.10
Tracing route to 192.168.11.10 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 192.168.1.1
2 35 ms 20 ms 31 ms 10.255.255.2
3 18 ms 28 ms 32 ms 192.168.11.10$ tracert 192.168.1.150
Tracing route to 192.168.1.150 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 192.168.11.1
2 18 ms 23 ms 29 ms 10.255.255.1
3 25 ms 35 ms 29 ms 192.168.1.150Nov 19 21:37:02 charon 13[KNL] <con2000|2> querying policy 10.255.255.2/32|/0 === 10.255.255.1/32|/0 in failed, not found
$ iperf3 -c 192.168.11.10
Connecting to host 192.168.11.10, port 5201
[ 4] local 192.168.1.150 port 51858 connected to 192.168.11.10 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.01 sec 256 KBytes 2.07 Mbits/sec
[ 4] 1.01-2.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 6.00-7.01 sec 0.00 Bytes 0.00 bits/sec
[ 4] 7.01-8.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 9.00-10.02 sec 0.00 Bytes 0.00 bits/sec
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.02 sec 256 KBytes 209 Kbits/sec sender
[ 4] 0.00-10.02 sec 7.97 KBytes 6.52 Kbits/sec receiverThe_Saint - check that your local and remote assignment is different, in the screenshot it looks like you have both local and remote as the same /32 (10.0.255.248)?
-
@bradlay
Thank you for your reply Bradly. This is my config
I used PFShell to edit the fields manually though it doesn't seem to take the$config['ipsec']['phase2'][0]['remoteid']['type'] = "network"; $config['ipsec']['phase2'][1]['remoteid']['type'] = "network";
For your issue, does your FW actually have interfaces for your VTI (besides the IPSec)?
Also, do you have MSS settings enabled? -
Is the VTI patch needed since 4.2.2 patch2, seeing an odd issue where SSH hangs looks like an MTU issue but it doesn't seem to make a blind bit of difference as to what I set the MSS to in the Ipsec settings.
This was on a new deploy, though it was an LRO issue with vmware, but since upgraded my other firewall from 4.2.2 p1 with the VTI patch to 4.2.2 p2 and are now having the same issue (that one runs in proxmox)
Edit:
Setting the MTU on the VTI interface slightly higher than the MSS on IPSEC > Advanced and lower than the physical interface seemed to fix it
MTU on PHY: 1500
MTU on VTI: 1450
MSS on IPSEC > Advanced 1400It took me way to long to get to the bottom of that, i'm off to grab a coffee
-
@dragon2611 any update? I have been having a reoccurring issue, both ssh issues, and over all routing and connectivity issues through the VTI tunnel. I am also have the phase2 reestablish and not kill off old session/id.
I followed the hangouts setup verbatim. I know its the VTI as communication via openvpn and client if flawless. -
Setting 1400 for MSS (advanced settings on the IPSEC config) and then setting MTU of 1450 on the VTI interface itself (once you've assigned it via assign interface you should then be able to change it's MTU) seemed to fix it for me.
This is a tunnel over a link that has an MTU of 1500, if you have a tunnel going over something with a lower MTU (E.g PPPoE) you might have to adjust the values downwards slightly.
-
It sounds like there is a Bug that causes the MTU set on the VTI interfaces to revert on a reboot/restart.
Looks like it's already in but as a feature request - https://redmine.pfsense.org/issues/9111 - I'd argue it's a bug because it breaks things by causing MTU issues on the tunnel. -
Has anyone found a way to use Gateway Monitor with Routed IPsec (VTI)?
I'm attempting to add the Routed IPsec (VTI) tunnel to a Gateway Group, but if/when the IPSEC tunnel goes down, I need the traffic to traverse an alternate gateway.
Thanks! -
I have not, I have had a really tough time with routing BGP over the VTI, and even static over VTI. Regular IPSEC seems to work fine. There is something broken with VTI, so be aware.
-
@mountainlion said in IPSEC VTI Tunnels:
I have not, I have had a really tough time with routing BGP over the VTI, and even static over VTI. Regular IPSEC seems to work fine. There is something broken with VTI, so be aware.
Routed IPSec (VTI) works great for me. Within the firewall rules, I can force certain hosts or entire interfaces to route all their traffic over the IPSec tunnel by forcing the gateway. But what I can't figure out is how to implement gateway monitoring for that 'gateway'. I need the ability for that traffic to failover to a secondary gateway, should the IPSec tunnel go down. Thanks in advance for anyone who can assist.
-
@AndrewBucklin Did you go to {system/ routing / Gateways ?
Then look for the field that says "Monitor Gateway"
Let me know if that works. -
@mountainlion No, it doesn’t work. No matter what IP I enter for the Monitor IP, the status will never change to “up”. I can only force it up by disabling gateway monitoring.
-
@AndrewBucklin
Assuming you have your ACL for that interface setup properly....