Hi all, Dpd and nat keepalive only work on IKE layer, not on the CHILD_SAs that you want.
Use auto=route, then bring up the tunnel manually once. Auto=route makes strongswan install trap policies for the traffic. That should improve reliability. The newest release brought a new value for start_acrion or use with swanctl/vici that enables installing of trap policies and starting of the tunnel when the daemon starts. Kind regards Noel Am 17. August 2022 13:35:08 UTC schrieb "Dr. Rolf Jansen" <[email protected]>: >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 = .... > >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? > >Or may I use the action „hold“? Usually the WAN-IP of the G4 router changes >upon down/up cycling. I guess this would confuse the trap policy, which will >catch matching traffic, won’t it? > >Thank you very much. > >Best regards > >Rolf Jansen > >> Am 17.08.2022 um 09:56 schrieb Michael Schwartzkopff <[email protected] >> <mailto:[email protected]>>: >> >> On 17.08.22 14:50, Dr. Rolf Jansen wrote: >>> Hello, >>> >>> The IKEv2 tunnels are established between device controllers in a remote >>> pilot plant in Spain, which is connected to the internet by a G4 mobile >>> router, and an AWS-EC2 instance in Frankfurt. On both sides strongSwan >>> v5.9.6 is installed and the OS is FreeBSD 13.0-RELEASE. Both sides are >>> behind NAT and receive their local IP via DHCP. For this reason I added on >>> both sides static local alias IPs of another reserved block to the >>> respective network adapter. >>> >>> Mobile connections are not as stable as wired ones, and quite frequently we >>> suffer connection losses. In the pilot plant are two almost identical >>> device controllers, and both establish its own IPsec tunnel to said EC2. >>> Usually both are down at the same time. This tells me, that origin of the >>> connection loss is external, and out of my control. I want to focus on how >>> to reliably bring them up again, once the connection was lost. >> >> >> That is exactly why Dead-Peer-Detection was included in IKEv2. Did you try >> using DPD? >> >> >> >>> So, I wrote a script which on the remote sites checks the IPsec status of >>> the connection, and calls „ipsec up“, in case it is down. The problem is >>> now, that „ipsec status“ seems to think it is up even if the connection is >>> broken and according to the logs, charon keeps on for hours happily sending >>> keep alive messages to the IP of the AWS-EC2 instance which at the same >>> time does send keep alives as well to its peers and everybody does it over >>> the already broken connections. >>> >>> I experimented with mobike = YES, but it did not make a difference. >>> >>> >>> Questions: >>> >>> Is there a more reliable way than „ipsec status“ for knowing whether a >>> IPsec tunnel went down? >>> >>> I am not 100 % sure, but it seems that „ipsec up“ does not always bring a >>> broken connection up again, should I call something else? >>> >>> The more drastic solution would be to let the remote site ping the internal >>> alias address of the EC2 and in case the connection is broken, simply call >>> „service strongswan restart“. However, If I need to refrain to this >>> measure, for what reason do we have „ipsec status“ and „ipsec up“ then? >>> >>> Best regards >>> >>> Rolf Jansen >> >> >> Mit freundlichen Grüßen, >> >> -- >> >> [*] sys4 AG >> https://sys4.de <https://sys4.de/>, +49 (89) 30 90 46 64 >> Schleißheimer Straße 26/MG,80333 München >> Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 >> Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief >> Aufsichtsratsvorsitzender: Florian Kirstein > Sent from mobile
