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 <m...@sys4.de > <mailto:m...@sys4.de>>: > > 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
