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



  • 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



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



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


Log in to reply