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

[Starko]

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!

[cmb]

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?

[Starko]

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:

[cmb]

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?

[Starko]

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?

[cmb]

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