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

    Multiple P2's show on PFsense to PFsense connections with same routes??

    Scheduled Pinned Locked Moved IPsec
    3 Posts 2 Posters 483 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.
    • WB3FFVW
      WB3FFV
      last edited by

      I am just curious if this is a bug, or if I am possibly setting up something wrong in IPsec for my PFsense connections. The IPsec sessions seem to be working OK for the most part, but over a little time, I can go into status, and look at the P2's for some VPN's that are running, and see they have anywhere from 2 to sometimes a half a dozen or more of the exact same P2's for the same IP range. Usually all but 1 shows 0 data movement, but they still show up. I have found just disconnecting the connection and letting it reconnect gets it back to just one P2, but figure there has to be some reason for this.

      Here is one of my VPN sessions, here is one showing the duplicate:

      P1:

      con16000: #5294 Bill's Home 50.x.x.x 50.x.x.x 73.y.y.y 73.y.y.y IKEv2
      responder 18394 seconds (05:06:34) AES_GCM_16

      PRF_AES128_XCBC
      ECP_512_BP ESTABLISHED
      10349 seconds (02:52:29) ago

      P2:

      con16000:
      #4473 10.3.0.0/16
      Local: c6a2a241
      Remote: ceb830f6 192.168.4.0/24
      Rekey: 222 seconds (00:03:42)
      Life: 272 seconds (00:04:32)
      Install: 3328 seconds (00:55:28) AES_GCM_16

      ECP_512_BP
      IPComp: none Bytes-In: 0 (0 B)
      Packets-In: 0
      Bytes-Out: 0 (0 B)
      Packets-Out: 0

      con16000:
      #4474 10.3.0.0/16
      Local: c0945201
      Remote: c135d308 192.168.4.0/24
      Rekey: 224 seconds (00:03:44)
      Life: 284 seconds (00:04:44)
      Install: 3316 seconds (00:55:16) AES_GCM_16

      ECP_512_BP
      IPComp: none Bytes-In: 6,624 (6 KiB)
      Packets-In: 80
      Bytes-Out: 11,104 (11 KiB)
      Packets-Out: 80

      K 1 Reply Last reply Reply Quote 0
      • K
        Konstanti @WB3FFV
        last edited by

        @WB3FFV
        Strongswan developer's explanation

        That's a known problem if you combine break-before-make reauthentication with trap policies. There is a short time after the old SA has been terminated and while the new one is established during which no SA is installed into the kernel. But since the trap policies are still installed, new acquires might get triggered by the kernel if there occurs to be matching traffic at that time, which will create an additional CHILD_SA (which in turn gets recreated during the next reauthentication). To avoid that, either use make-before-break reauthentication (creates the new IKE and CHILD_SAs overlapping) or just use IKE_SA rekeying to replace the keying material without any interruption at all. For more details, refer to ExpiryRekey.

        1 Reply Last reply Reply Quote 0
        • WB3FFVW
          WB3FFV
          last edited by

          So looking at the VPN config screen (I use IKEv2), I see under advanced options for Disable Rekey, and Disable Reauth, along with a margintime setting. Is this saying that I just need to select "disable rekey" to make this work correctly??

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