IPSec problem with pfSense 2.3 - DPD path probing fails
-
Hello,
I am using a IPSec IKEv2 Connection on pfSense. The configuration of IPSec is fine and worked with 2.2.6 without problems.
After the installation of 2.3 version the IPSec clients still connect to pfSense and I can connect to certain IPs in the pfSense Network.
But after a minute or so all of a sudden I am unable to make a connection to the remote IPs anymore.
It still displays a active connection in the client but it seems that it is not alive anymore. When I dis- and reconnect everything works again for a couple of minutes. The problem exists whether I connect with OS X 10.11, iPhone (both Built-In Clinet) or Android (StrongSwan Client).
An OpenVPN connection works flawless.I think the problem is due to DPD (Dead peer connection). I do not understand why the DPD is established via the LAN ( .7 ) and not the WAN ( .8 )? Because there only exist a WAN Firewall rule to allow incoming connections via port 4500. LAN (out) should work to any IP with this rule:
IPv4 * LAN net * * * * none Default allow LAN to any rule
IPv6 * LAN net * * * * none Default allow LAN IPv6 to any ruleNAT Outbound is manual.
This says my log (IPs modified with xx):
Apr 14 22:28:35 charon 12[IKE] <con1|15> giving up after 10 path probings Apr 14 22:28:33 charon 12[NET] <con1|15> sending packet: from 10.21.30.7[4500] to xx.227.10.33[4500] (128 bytes) Apr 14 22:28:33 charon 12[IKE] <con1|15> checking path 10.21.30.7[4500] - xx.227.10.33[4500] Apr 14 22:28:33 charon 12[IKE] <con1|15> path probing attempt 10 Apr 14 22:28:30 charon 12[NET] <con1|15> sending packet: from 10.21.30.7[4500] to xx.227.10.33[4500] (128 bytes) Apr 14 22:28:30 charon 12[IKE] <con1|15> checking path 10.21.30.7[4500] - xx.227.10.33[4500] Apr 14 22:28:30 charon 12[IKE] <con1|15> path probing attempt 9 Apr 14 22:28:28 charon 12[NET] <con1|15> sending packet: from 10.21.30.7[4500] to xx.227.10.33[4500] (128 bytes) Apr 14 22:28:28 charon 12[IKE] <con1|15> checking path 10.21.30.7[4500] - xx.227.10.33[4500] Apr 14 22:28:28 charon 12[IKE] <con1|15> path probing attempt 8 Apr 14 22:28:25 charon 12[NET] <con1|15> sending packet: from 10.21.30.7[4500] to xx.227.10.33[4500] (128 bytes) Apr 14 22:28:25 charon 12[IKE] <con1|15> checking path 10.21.30.7[4500] - xx.227.10.33[4500] Apr 14 22:28:25 charon 12[IKE] <con1|15> path probing attempt 7 Apr 14 22:28:23 charon 12[NET] <con1|15> sending packet: from 10.21.30.7[4500] to xx.227.10.33[4500] (128 bytes) Apr 14 22:28:23 charon 12[IKE] <con1|15> checking path 10.21.30.7[4500] - xx.227.10.33[4500] Apr 14 22:28:23 charon 12[IKE] <con1|15> path probing attempt 6 Apr 14 22:28:20 charon 05[NET] <con1|15> sending packet: from 10.21.30.7[4500] to xx.227.10.33[4500] (128 bytes) Apr 14 22:28:20 charon 05[IKE] <con1|15> checking path 10.21.30.7[4500] - xx.227.10.33[4500] Apr 14 22:28:20 charon 05[IKE] <con1|15> path probing attempt 5 Apr 14 22:28:18 charon 05[NET] <con1|15> sending packet: from 10.21.30.7[4500] to xx.227.10.33[4500] (128 bytes) Apr 14 22:28:18 charon 05[IKE] <con1|15> checking path 10.21.30.7[4500] - xx.227.10.33[4500] Apr 14 22:28:18 charon 05[IKE] <con1|15> path probing attempt 4 Apr 14 22:28:15 charon 05[NET] <con1|15> sending packet: from 10.21.30.7[4500] to xx.227.10.33[4500] (128 bytes) Apr 14 22:28:15 charon 05[IKE] <con1|15> checking path 10.21.30.7[4500] - xx.227.10.33[4500] Apr 14 22:28:15 charon 05[IKE] <con1|15> path probing attempt 3 Apr 14 22:28:13 charon 05[NET] <con1|15> sending packet: from 10.21.30.7[4500] to xx.227.10.33[4500] (128 bytes) Apr 14 22:28:13 charon 05[IKE] <con1|15> checking path 10.21.30.7[4500] - xx.227.10.33[4500] Apr 14 22:28:13 charon 05[IKE] <con1|15> path probing attempt 2 Apr 14 22:28:10 charon 05[NET] <con1|15> sending packet: from 10.21.30.7[4500] to xx.227.10.33[4500] (128 bytes) Apr 14 22:28:10 charon 05[IKE] <con1|15> checking path 10.21.30.7[4500] - xx.227.10.33[4500] Apr 14 22:28:10 charon 05[IKE] <con1|15> path probing attempt 1 Apr 14 22:28:07 charon 05[NET] <con1|15> sending packet: from 10.21.30.7[4500] to xx.227.10.33[4500] (128 bytes) Apr 14 22:28:07 charon 05[IKE] <con1|15> checking path 10.21.30.7[4500] - xx.227.10.33[4500] Apr 14 22:28:07 charon 05[ENC] <con1|15> generating INFORMATIONAL request 0 [ N(NATD_S_IP) N(NATD_D_IP) ] Apr 14 22:28:07 charon 05[IKE] <con1|15> sending DPD request Apr 14 22:28:07 charon 15[IKE] <con1|15> sending keep alive to xx.227.10.33[4500] Apr 14 22:26:58 charon 14[NET] <con1|15> sending packet: from 10.21.30.8[4500] to xx.227.10.33[4500] (288 bytes) Apr 14 22:26:58 charon 14[ENC] <con1|15> generating IKE_AUTH response 5 [ AUTH CPRP(ADDR DNS SUBNET) N(ESP_TFC_PAD_N) SA TSi TSr N(AUTH_LFT) N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) ] Apr 14 22:26:58 charon 14[IKE] <con1|15> CHILD_SA con1{16} established with SPIs cd2368e0_i 0f88b971_o and TS 10.21.30.0/24|/0 === 10.21.32.1/32|/0</con1|15></con1|15></con1|15></con1|15></con1|15></con1|15></con1|15></con1|15></con1|15></con1|15></con1|15></con1|15></con1|15></con1|15></con1|15></con1|15></con1|15></con1|15></con1|15></con1|15></con1|15></con1|15></con1|15></con1|15></con1|15></con1|15></con1|15></con1|15></con1|15></con1|15></con1|15></con1|15></con1|15></con1|15></con1|15></con1|15></con1|15></con1|15></con1|15>
Any ideas?
-
Why are your WAN and LAN on the same subnet? That'll lead to various unpredictable at best networking circumstances. Which is the IPsec bound to?
-
-> cmb
Thank you for your statement. You are absolutely right that it is not the "finest" solution that WAN and LAN are on the same subnet but they are segregated via VLAN and not bridged. The WAN uses a gateway that`s why it has a static ip. This gateway is used by another network with the same subnet which is not connected to the first network with the same subnet. This needs to be changed but the reason was a connection of two networks that were not planned intentionally and the change has not been done yet.
In the "first" subnet with pfSense the IPSec clients are in the subnet 10.21.32.0/24, LAN is 10.21.30.0/24 (OpenVPN Clients in 10.21.31.0/24).
I changed the subnet for WAN (10.21.29.0/24) for testing on the weekend but the problem remains.
In the meantime I could figure out the problem. The problem only exists when MOBIKE is enabled (a new feature in 2.3 as far as I remember). If MOBIKE is disabled the DPD is sent via the WAN as intended. If MOBIKE is enabled the DPD is sent via LAN interface. So there could be a problem with the implementation of MOBIKE.