One connection drops the other

Eduardox

Hi,

I have a strange problem since upgrading to 2.5.2. In 2.5.1 it's working well, but not in 2.5.2. Unfortunately I don't see this mentioned anywhere as a bug, so I don't know what exactly is wrong.

I have a pfsense with has 3 IPsec connections:

To another pfsense in another location
To a Fritz!BOX in yet another location
"Road warriors", to dial in from laptop on the move (Shrew), and iPhone (native client)

Before upgrading to 2.5.2 all three could be used at the same time. But now, I can't connect anymore when connection 2 is already connected. The error on the VPN client is "shared secret is wrong". However, if I disconnect "2" from above, then the client CAN connect without any problem. If I then re-connect "2", then they are all 3 connected at the same time. However, when disconnecting 3, and then reconnecting 3, it fails again.

The status of "1" has no influence. "2" and "3" can only be at the same time when "3" is connected first.

Now how weird is that?

Thanks for any tips...

DylanW

I'm seeing something very similar.

I have a pfSense 2.5.2 box with two IPSEC VPNs configured on it, one as an L2TP/IPSEC VPN for mobile users and another as a tunnel for a remote site with a dynamic IP.

It appears that if the tunnel is enabled then StrongSwan matches the mobile users to the ike config of the tunnel and the connection fails. Disable the tunnel and the mobile client can connect, enabling the tunnel afterwards allows the tunnel to connect.

I believe this is the relevant part of the IPsec logs from the pfSense box:

Oct 18 14:33:02 charon 76621 09[CFG] <213> looking for an IKEv1 config for aaa.aaa.aaa.aaa...bbb.bbb.bbb.bbb
Oct 18 14:33:02 charon 76621 09[CFG] <213> candidate: 0.0.0.0/0, ::/0...0.0.0.0/0, ::/0, prio 28
Oct 18 14:33:02 charon 76621 09[CFG] <213> candidate: aaa.aaa.aaa.aaa...0.0.0.0, prio 1052
Oct 18 14:33:02 charon 76621 09[CFG] <213> found matching ike config: aaa.aaa.aaa.aaa...0.0.0.0 with prio 1052

The tunnel is set to use a User distinguished name as its peer identifier, however StrongSwan seems to be ignoring that and instead tries to match the IKE config by picking the one with the matching IP addresses.

I'm not sure how to fix it though.

Edit: The above logs were the result of a connection attempt from the native Windows 10 VPN client.

DylanW

I found this in the StrongSwam documentation which is likely relevant to my issue:

The native Windows VPN Client does not send a responder identity (IDr) when initiating an IKE_SA, so two connection configurations can only be distinguished if their authentication type differs or the clients send different certificate for the different certificates' root CAs.

Eduardox

Thanks for your message. I still have this problem, and can't find a solution for it. The only "fix" I found is downgrading to 2.5.1, then it works immediately again :-/

I am actually not using the native Windows 10 client, but the Shrewsoft VPN client on Windows. On iOS I use the native iOS client.

This quote you found in the StrongSwan documentation, is that only since the version that is used in pfSense 2.5.2 ?

Eduardox

@dylanw Hi, did you find a solution for this? Because even with the new 2.6.0 beta I experience the same issue. Still staying on 2.5.1 for that reason.

Thanks