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

    IPSec Site-to-Site stops working - Renegotiation Errors - Prefer Old IPsec SA

    Scheduled Pinned Locked Moved IPsec
    6 Posts 2 Posters 2.2k 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.
    • S
      Starko
      last edited by

      Hello,
      we face the problem, that since pfSense 2.2.x we often have to force start IPsec connections on the shell. Both IKEv1 and IKEv2 connections stop (randomly?) during working hours and have to be started again by "ipsec up con1" for example. Restart through WebGUI doesn't work most of the time.
      In the wiki I found the following article: https://doc.pfsense.org/index.php/IPsec_Troubleshooting#Renegotiation_Errors
      There it states in the first suggestion: "uncheck* Prefer Old IPsec SA (VPN > IPsec, Advanced Settings tab on pfSense 2.2+)"
      It seems that this tips are outdated, as this setting doesn't exist anymore.
      What would be the appropriate way for 2.2.5+ to troubleshoot or even better solve this problem?
      Thank you everybody!

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

        That option is off and no longer exists in 2.2.3 and newer. I updated that page accordingly.

        The GUI status page runs the exact same 'ipsec up conX' when you start a connection there.

        What device are you connecting to? What do your IPsec logs show at a time you need to start it manually?

        1 Reply Last reply Reply Quote 0
        • S
          Starko
          last edited by

          I asked the other side. It's a Sonicwall TZ 210

          We just a had a another interuption and here are the logs. Nothing I could see in it:

          Feb 16 10:39:57	charon: 10[NET] <con1|905> sending packet: from 89.246.240.30[4500] to 87.139.152.86[4500] (76 bytes)
          Feb 16 10:39:57	charon: 10[ENC] <con1|905> generating INFORMATIONAL response 83 [ ]
          Feb 16 10:39:57	charon: 10[ENC] <con1|905> parsed INFORMATIONAL request 83 [ ]
          Feb 16 10:39:57	charon: 10[NET] <con1|905> received packet: from 87.139.152.86[4500] to 89.246.240.30[4500] (76 bytes)
          Feb 16 10:39:56	charon: 10[IKE] <con1|905> CHILD_SA con1{11050} established with SPIs c02ca620_i d08853d6_o and TS 172.17.0.0/24|/0 === 192.168.229.0/24|/0
          Feb 16 10:39:56	charon: 10[ENC] <con1|905> parsed CREATE_CHILD_SA response 127 [ SA No KE TSi TSr ]
          Feb 16 10:39:56	charon: 10[NET] <con1|905> received packet: from 87.139.152.86[4500] to 89.246.240.30[4500] (332 bytes)
          Feb 16 10:39:56	charon: 10[NET] <con1|905> sending packet: from 89.246.240.30[4500] to 87.139.152.86[4500] (364 bytes)
          Feb 16 10:39:56	charon: 10[ENC] <con1|905> generating CREATE_CHILD_SA request 127 [ N(ESP_TFC_PAD_N) SA No KE TSi TSr ]
          Feb 16 10:39:56	charon: 10[IKE] <con1|905> establishing CHILD_SA con1
          Feb 16 10:39:56	charon: 15[CFG] received stroke: initiate 'con1'</con1|905></con1|905></con1|905></con1|905></con1|905></con1|905></con1|905></con1|905></con1|905></con1|905>
          
          [2.2.5-RELEASE][admin@fw01.domain.local]/root: ipsec up con1
          establishing CHILD_SA con1
          generating CREATE_CHILD_SA request 127 [ N(ESP_TFC_PAD_N) SA No KE TSi TSr ]
          sending packet: from 89.246.240.30[4500] to 87.139.152.86[4500] (364 bytes)
          received packet: from 87.139.152.86[4500] to 89.246.240.30[4500] (332 bytes)
          parsed CREATE_CHILD_SA response 127 [ SA No KE TSi TSr ]
          CHILD_SA con1{11050} established with SPIs c02ca620_i d08853d6_o and TS 172.17.0.0/24|/0 === 192.168.229.0/24|/0
          connection 'con1' established successfully
          [2.2.5-RELEASE][admin@fw01.domain.local]/root:
          
          1 Reply Last reply Reply Quote 0
          • C
            cmb
            last edited by

            The logs there start when you manually brought it up. From there looks like just a normal negotiation. Were there any IPsec logs prior to when you forced it up?

            1 Reply Last reply Reply Quote 0
            • S
              Starko
              last edited by

              Sorry @cmb, I did understand you wrong. I thought you wanted what happens in the log after I manually forced it to start.
              But we solved this particular problem otherwise. The Administrator from the Sonicwall did an update and since a few days I didn't get another info for this problem.

              But we still have this problem between pfSense Boxes. The IPsec tunnel is offline and I want to start a RDP Session. But the tunnel doesn't start from the RDP request. I have to start it myself. Should I make a new topic for this? Or should I post concerning information here?

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

                Sounds like that's a completely separate issue so best to start a new thread to avoid confusing two unrelated things.

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