IPSEC VTI Tunnels

zhongfu

@abounde on pfSense.

You could probably just enable the network type field in the phase2 configuration page (with "Inspect Element"?) then configure accordingly, or you could try this in the pfSense shell (assuming you've only got one phase2 config -- if you've got more, just change the [0]s to the appropriate value)

parse_config(true);
$config['ipsec']['phase2'][0]['remoteid']['type'] = "network";
$config['ipsec']['phase2'][0]['remoteid']['netbits'] = 30;
write_config();

jimp

If that worked I can change the GUI to not lock down the remote.

I originally locked it down because of how the man page for if_ipsec(4) described configuring the interface, it only had a mask on the local component not the remote. If the local is set to /30 it should have the right mask for the interface as a whole. Is that not happening for you?

zhongfu

@jimp I think it might be because strongswan doesn't know where to route the packets (?) -- just changing the strongswan configuration to remote_ip/30 for the remote allows traffic to go through

AboundE

@zhongfu thanks for your help, I did the changes (with "Inspect Element"?) and now my VPN Phase 2 setup is this:

0_1535723585419_028a08b2-c8f9-4489-8383-269cb2b063d9-image.png

Now, I can ping from the LAN behing the EdgeRouter to the LAN Interface of the pfSense, but I can't ping to a host inside the LAN behind the pfSense.

In the opposite by, from the LAN behind the pfSense to the LAN behind the EdgeRouter I can't ping anything. But again, I can ping the LAN Interface of the EdgeRouter.

The firewall rules in both LAN interfaces are complete open.

My route table in the pfSense is this:
0_1535723860089_b51a97b6-179a-455d-bd31-c2ca054d2e1c-image.png

And in my EdgeRouter is this:
0_1535723934449_23ae1de7-43d7-4ae9-a434-1bc283237f69-image.png

Could you check in your network/lab if you can ping from host to host, passing by the VPN tunnel.?

Thanks

jimp

I pushed a change to allow the remote type to be changed to Network. It defaults to address, but once set to Network it will retain that value.

AboundE

@zhongfu could you paste here the EdgeRouter configuration?

I think my issue now is on the EdgeRouter side.

Thanks

zhongfu

@abounde don't think I can help you there -- I'm using BGP for my setup, and the ERL on the other end isn't mine.

maybe you'd want your gateway to be the VTI IP of the other end though? (e.g. 10.6.106.2 instead of ipsec1000 for the pfSense site, etc)

zhongfu

@jimp It looks like the VTI interface won't come up now, because if_ipsec(4) won't take a subnet mask for the remote component. However, strongswan doesn't seem to route packets between local and remote if the mask for rightsubnet isn't the same as that for leftsubnet

Perhaps it might be a good idea to strip the subnet mask from the remote before running ifconfig ipsecX local_ip/30 remote_ip, or something similar like only accepting an address for the remote but adding the subnet mask from local_ip to remote_ip in the strongswan config?

jimp

I reverted the commit I made to allow changed on that field for now, since it was broken.

There seems to be two possible paths here:

Still allow the field to be changed but (a) add input validation to prevent different masks and (b) ignore the mask bits when running ifconfig -- this could be confusing to the user though
Prevent the field from being changed and inject the local mask bits into rightsubnet in the strongSwan config.

Option #2 is much easier, but I am left to wonder how well that will interact with third party implementations that work now when the remote is an address. It may be fine, but needs testing.

If you want to try that, use the system patches package to revert da54e84ae79328a87b4a319239bb1b14d7ed2ce6 and then add the attached patch as another entry.
0_1536597185830_vti_force_rightsubnet_bits.diff

bepo

@jimp said in IPSEC VTI Tunnels:

Option #2 is much easier, but I am left to wonder how well that will interact with third party implementations that work now when the remote is an address. It may be fine, but needs testing.

Hello @jimp, just to inform here is another user wating for a fix.

SonicWall needs a network as local network. For this i am getting this error:

IKEv2 Responder: Peer's destination network does not match VPN Policy's [Local Network]
VPN Policy: XXXNAMEOFVPNXXX; Proposed network: 172.27.3.1-172.27.3.1

It would be fine, if we could select a network as remote network on pfSense. Thanks a lot!

jimp

Palo Alto seems unhappy as well. I have a new patch to test but it does need testing. It comes up and works for me but I don't have access to any of these other devices (ubnt, sonicwall, PA, etc). Also need to be sure it doesn't interfere with other non-IPsec traffic and other non-VTI IPsec tunnels.

From my other post:

Try the attached patch and see if it helps. I could not get the VTI to come up and pass traffic with only 0.0.0.0/0 in the rightsubnet and leftsubnet, but it did seem to connect and work with the attached patch that has both the VTI endpoints and all zeroes. I haven't testing to see if it interferes with anything else yet, though, just VTI itself (BGP connects and exchanges routes, traffic passes)

0_1538745996158_ipsec-vti-0.0.0.0.diff

Use the System Patches package to apply the diff, or make the changes by hand. After applying the patch, stop IPsec, then edit/save/apply the IPsec VTI P1 or P2 and it should restart with the new policy in place.

turbulence

Hi Jim,

Long time pfSense user here.

Thought I would sign up to the forum to contribute to this. I have just installed patch 0_1538745996158_ipsec-vti-0.0.0.0.diff and setup a VTI between the pfSense and an EdgeRouter 4 (running the latest firmware) and I can report that the VPN is now working correctly. I'll let you know if I come across any subsequent strange behaviors, but everything is looking good so far.

fsamareanu

@jimp I've encountered a similar issue (I could ping the tunnel IP addresses but nothing else) by doing a pfsense-debian buster ipsec connection. I can prepare a testcase on a vultr VM pair if required and ship you the credentials.

EDIT: I still see these in the log file(s) when I go to status-ipsec:

But the tunnels are up and passing traffic.

jimp

@fsamareanu said in IPSEC VTI Tunnels:

@jimp I've encountered a similar issue (I could ping the tunnel IP addresses but nothing else) by doing a pfsense-debian buster ipsec connection. I can prepare a testcase on a vultr VM pair if required and ship you the credentials.

But the tunnels are up and passing traffic.

Is this with the new patch applied? If not, apply that patch.

EDIT: I still see these in the log file(s) when I go to status-ipsec:

Oct 8 13:04:37 192.168.100.1 charon: 04[KNL] <con3000|3> querying policy 0.0.0.0/0|/0 === 0.0.0.0/0|/0 in failed, not found

I'm not terribly surprised there, since VTI doesn't actually install the policy in the kernel since it isn't needed. That may be prohibitively difficult to suppress that warning but if I do end up committing this patch we can look into it after.

fsamareanu

@jimp the warning is with the patch applied. The error was there before as well, just showing the /30 subnet and the corresponding remote tunnel ip.

I have not tested the pfsense-Linux ipsec tunnel after the pfsense patch. Will get to it tomorrow and update here.

BluRay

@turbulence said in IPSEC VTI Tunnels:

Hi Jim,

Long time pfSense user here.

Thought I would sign up to the forum to contribute to this. I have just installed patch 0_1538745996158_ipsec-vti-0.0.0.0.diff and setup a VTI between the pfSense and an EdgeRouter 4 (running the latest firmware) and I can report that the VPN is now working correctly. I'll let you know if I come across any subsequent strange behaviors, but everything is looking good so far.

Mind sharing your configuration?
I am trying to get IPSec VTI running between PfSense and EdgeRouter X but i'm not able to get it working. (I already applied latest patch)
alt text

Logging:

Oct 12 09:11:40	charon		12[KNL] creating acquire job for policy X.X.X.X/32|/0 === X.X.X.X/32|/0 with reqid {0}
Oct 12 09:11:40	charon		12[KNL] received an SADB_ACQUIRE with policy id 8936 but no matching policy found
Oct 12 09:11:38	charon		06[CFG] vici client 148 disconnected
Oct 12 09:11:38	charon		16[CFG] vici client 148 requests: list-sas
Oct 12 09:11:38	charon		16[CFG] vici client 148 registered for: list-sa
Oct 12 09:11:38	charon		08[CFG] vici client 148 connected

turbulence

Sure thing.

Here's the ER4 config to start with. BTW, you need to be using IKEV2.

==PEER CONFIG==
show vpn ipsec site-to-site peer X.X.X.X
authentication {
mode pre-shared-secret
pre-shared-secret SECRETGOESHERE
}
connection-type initiate
description TUNNEL-NAME-HERE
ike-group FOO4
ikev2-reauth yes
local-address Y.Y.Y.Y
vti {
bind vti4
esp-group FOO4
}

==ESP CONFIG==
show vpn ipsec esp-group FOO4
compression disable
lifetime 28800
mode tunnel
pfs dh-group14
proposal 1 {
encryption aes256
hash sha256
}

==IKE CONFIG==
show vpn ipsec ike-group FOO4
ikev2-reauth yes
key-exchange ikev2
lifetime 28800
proposal 1 {
dh-group 14
encryption aes256
hash sha256
}

==VTI CONFIG==
show interfaces vti vti4
address 10.10.202.2/30
mtu 1436

==ROUTE CONFIG==
show protocols static interface-route 172.24.16.0/24
next-hop-interface vti4 {
description TUNNEL-NAME-HERE
}

turbulence

And here's the PFSense configuration.

Let me know if you need any further assistance!

BluRay

@turbulence said in IPSEC VTI Tunnels:

And here's the PFSense configuration.

Let me know if you need any further assistance!

Thank you for the information. Will try it out later today and report back.

BluRay

@turbulence said in IPSEC VTI Tunnels:

And here's the PFSense configuration.

Let me know if you need any further assistance!

Ok, I tried to do it with IKEv2 and instead of Type 'Network' on Remote Network in PfSense Phase 2 setting, I used Type 'Address'.

With those settings the tunnel will come online. But I'm still not able to pass traffic.
What I found out is the following:
When I start a packetdump on PfSense I see ICMP traffic. (192.168.111.1 --> 192.168.111.2)
On EdgeRouter X side I see the ICMP messages arrive and the router also responds, but the response packets never reach the IPSEC1000 interface on the PfSense.

PfSense
alt text

EdgeRouter
alt text