4. IPSec problem with pfSense 2.3 - DPD path probing fails

IPSec problem with pfSense 2.3 - DPD path probing fails

  • E

    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 rule

    NAT 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?

    0
  • C

    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?

    0
  • E

    -> 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.

    0
Log in to reply
 

Products

Services

Support

News

Resources

Company

Our Mission

We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

Subscribe to our Newsletter

Product information, software announcements, and special offers. See our newsletter archive for past announcements.

© Copyright 2002 - 2019 Rubicon Communications, LLC | Privacy Policy