[strongSwan] Issues with maintaining IKEv2 tunnels

[Dr. Rolf Jansen]

> Am 17.08.2022 um 10:45 schrieb Michael Schwartzkopff <ms at sys4.de>:
> 
> On 17.08.22 15:35, Dr. Rolf Jansen wrote:
>> I know what DPD is. Years ago, I used it with the old racoon of the ipsec-tools then with IKEv1, and in racoon.conf I set the dpd_delay and let it after dpd_maxfail call a script with the pahse1_dead argument.
>> 
>> Some times ago, I read the manual ipsec.conf of strongSwan, and I did not realize that „dpdaction = none (default)“ also deactivates DPD and not only the action. Your reply let me read this part again more carefully, and I will try with dpdaction = ....
> 
> 
> Yes. DPD ind IKEv1 was, well, not good.
> 
> 
>> Now my guess is, that I need to use the action „clear“ on both sides once the mobile connection went down, since it usually does not come back in seconds, most of the times even not in minutes. Then my script would reliably be informed by „ipsec status“ that the connection is down, won’t it?  And it could be brought up again using „ipsec up“ once the G4 router went back online, couldn’t it?
> 
> I suggest the dpd_action=clear on the central VPN server and "restart" on the sattelites.
> 
> If the connection is lost, the central server clears the connection and the remote clients re-establish the connections.

Thank you for the suggestion. I will try that. 

> Please be sure to have a dpd_timeout set in the config. Just test it. Watch the logs until the behaviour fits your needs.

I mentioned it only ones in the thread title, so you might have it overseen. This is about IKEv2 tunnels and according to the manual, dpdtimeout would be ignored for IKEv2.

Best regards

Rolf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20220817/90686167/attachment.html>