Allow DPD action adjustable in IPSec Phase 1

[agido-malter]

IPSec DPD action allow the following settings

CLEAR = after a loss of connection, IPSec tunnel will be closed or stopped
RESTART = after a loss of connection, IPSec starts to reconnect to peer

Default IPSec implementation in opnsense is clear, but it is not adjustable to restart. This make no sense in 24/7 environments, were a permanent IPSec tunnel is required.

ToDo:
Add in core/src/www/vpn_ipsec_phase1.php a checkbox for DPD action restart or a drop down for clear | restart.
If restart, change DBDACTION in ipsec.conf to restart

[AdSchellevis]

the dpdaction is changed according to the connection method at the moment, when set to route, it's value is restart

core/src/etc/inc/plugins.inc.d/ipsec.inc

Lines 1181 to 1185 in 139ef62

	if ($conn_auto == "route") {
	$dpdline = "dpdaction = restart";
	} else {
	$dpdline = "dpdaction = clear";
	}

not sure if we should change it, we could have an overwrite, but knowing this might already fix your issue

[agido-malter]

yes route could be an option, but not usable in a 24/7 environment. Route activates tunnel only on traffic, but than our monitoring fails. A overwrite would be a nice option

[sachaz]

Just for info, I don't know if it can help
I'm using a small crontab script to do my dpd with an OpnBSD IPSec

test=ipsec status | grep -A1 "INSTALLED, TUNNEL, reqid 1" |grep "$Remote_gateway_IP === 0.0.0.0/0"
if [ -z "$test" ]
then
ipsec restart
fi

[stumbaumr]

People activate DPD to make sure their tunnels are working and up. So as soon as DPD is activated why not just setting it to restart? If it starts flapping this should show up in the logs anyway...

[stumbaumr]

Just experienced a tunnel down event again while having a coffee. The modified ipsec.conf was unfortunately overwritten by the WebGUI previously so the tunnel did not restart . Had some complaints on my way back to my desk...

Moved the tunnel out of the WebGUI setup into the includes now (<-- does not work since it is a IPsec VTI tunnel... - I left the tunnel config now in the WebGUI and overwrite specific values using includes. See below).

Please take a decision here on how to go forward. The tunnel in question is a Route-based tunnel - at least those should have a dpdaction = restart.

[stumbaumr]

Fixing a broken link for a IKEv2 connection in a timely manner is a little bit more complicated:

• dpdtimeout is not used (https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection#General-Connection-Parameters )
• retransmission has to be configured in strongswan.conf (https://wiki.strongswan.org/projects/strongswan/wiki/Retransmission )

You should take this into account please...

So fixing this using the includes does the trick:

root@opnsense01:~ # cat /usr/local/etc/ipsec.opnsense.d/ipsec.con1.conf
conn con1
  dpdaction = restart
  dpddelay = 30s
root@opnsense01:~ # cat /usr/local/etc/strongswan.opnsense.d/strongswan.ikev2.conf
charon {
    retransmit_tries = 3
    retransmit_timeout = 3
    retransmit_base = 1
}
root@opnsense01:~ #

[ruffy91]

We have a ipsec tunnels between OPNSense 19.1.9 and Sophos UTM.
As the OPNSense is behind NAT she needs to initiate the connection.

When the Sophos gets rebooted (for example because of Firmware update) a clear command gets sent to the OPNSense.

Consequence is that the opnsense clears the tunnel and does not start it again, despite being set to Start immediate. The Sophos UTM is set to respond only and waits until the OPNSense starts the connection again.

So we tried to setup DPD, that the OPNSense would start the connection again after it gets down, but the dpdaction is clear instead of restart.

This means to us that a OPNSense firewall is not able to provide ipsec site-to-site connectivity when behind NAT.

[fichtner]

Is this still relevant in 19.7.4 and up?

[mimugmail]

Ad added the restart option for routed IPsec. No decision for tunnel mode yet

[stumbaumr]

From my point of view the dpd action set to restart is correct now if DPD is activated. But the charon settings for IKEv2 connections are still missing - so the restart in case of a disconnected/broken connection still takes a long time.

I suggest to also add my charon recommendation as documented above.

[AdSchellevis]

This issue has been automatically timed-out (after 180 days of inactivity).

For more information about the policies for this repository,
please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.

If someone wants to step up and work on this issue,
just let us know, so we can reopen the issue and assign an owner to it.