IPSec tunnels do not re-initiate

[dennis_u]

Situation:
main location: dns name to IP, OPNsense 27.7
remote location 1: dynamic IP, Juniper SRX
remote location 2&3: dynamic IP, OPNsense 27.7

If we restart the StrongSwan service at the main location or boot the OPNsense (because of updates, etc.), the remote OPNsenses do not re-establish IPSec connections, the SRX location does.

Looking to the remote machines: under VPN > IPsec > Status Overview there is a red cross in the P1 status. Only by clicking on the play button (on the right side) does the tunnel come back immediately or by a reboot.
We have now tested different configs in the connection method and with DPD, but did not have the desired success.

What does the IPSec config have to look like in order to automatically try to establish a connection again after the tunnel has been aborted/terminated? Any ideas (we have an temporary access to the remote machines, even if the tunnel are down)?

[Patrick M. Hausen]

Dead peer detection and close action come to mind as parameters to tweak.

[anicoletti]

We also had issues with the IPSEC Tunnels not re-establishing even with DPD setup. We ended up using Monit to monitor the IPSEC tunnels and restart if the tunnel ping failed.

[mimugmail]

Set keyingtries to -1 does the trick

[dennis_u]

Set keyingtries to -1 does the trick

It sounded promising, but neither setting it on the far end, nor on both ends brought back the tunnel. Only hitting the start button at the page "Status overview".

[dennis_u]

We also had issues with the IPSEC Tunnels not re-establishing even with DPD setup. We ended up using Monit to monitor the IPSEC tunnels and restart if the tunnel ping failed.

Good workaround. Unfortunately, we have no host on the far end to monitor the tunnel and to reset it. And to be honest, there must be an out-of-the-box solution based on the OPNsense IPSec configuration. There can be always a wire interruption, a firmware upgrade, you name it, which yields into a tunnel termination. There has to be a solution based on StrongSwan.

[Patrick M. Hausen]

What is your close action set to?

[dennis_u]

What is your close action set to?

Per default to None, but we tried every single option of this parameter, but no luck so far.

[mimugmail]

Set keyingtries to -1 does the trick

It sounded promising, but neither setting it on the far end, nor on both ends brought back the tunnel. Only hitting the start button at the page "Status overview".

Then set the type on start immediate on one site in addition to this

[dennis_u]

Then set the type on start immediate on one site in addition to this

Unfortunately that didn't work either.

But news about this: today we installed version 22.7.7 on a remote OPNsense. We also had to reboot the remote firewall to do this.
Since the update, the tunnel has been running as desired, we have also downconfigured the config attempts bit by bit in order to destabilize the tunnel again for the purpose of finding the cause - nothing. Currently it runs with the default IKEv2 settings, but with DPD. I can delete the SAs and stop/start the daemons, the tunnels are recreated immediately (respectively after the DPD timeout).

Theory 1: the software update to 22.7.7 did something
Theory 2: certain IPSec config changes only become active after a reboot

Next weekend I'll try to update a machine with an untouched config to 22.7.7, maybe I'll get a clue, if it related to the software version.