Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    IPSec problem with pfSense 2.3 - DPD path probing fails

    Scheduled Pinned Locked Moved IPsec
    3 Posts 2 Posters 1.3k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • E
      epionier
      last edited by

      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?

      1 Reply Last reply Reply Quote 0
      • C
        cmb
        last edited by

        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?

        1 Reply Last reply Reply Quote 0
        • E
          epionier
          last edited by

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

          1 Reply Last reply Reply Quote 0
          • First post
            Last post
          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.