IPsec Connections - IKE DPD Action "Restart" listed as "Start" does not restart/re-negotiate the connection when a peer dies.

[KYLE-HILL]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug
IKE Dead Peer-Detection Restart Action using the new "Connections - IKE Children UI" is showing as "Start" and does not actually force restart IKE re-negotiation upon a dead peer despite DPD timer being configured.

To Reproduce

Steps to reproduce the behavior:

1. Go to VPN -> IPsec -> Connections
2. Edit an existing connection or add a new one.
3. Scroll down to Children and Edit
4. Go to DPD Action and click on drop down. (Clear, Trap, Start)
5. Click on Start
6. See error

Expected behavior

The "Edit Child" UI naming should be corrected to say "Restart" and should also force restart a new IKE session after the specified IKE DPD delay is triggered by a dead-peer.

Describe alternatives you considered
None - This appears to be a bug with the updated core IPsec Plugin. I did not have this issue prior to migrating my "Legacy" IPsec VPN Connections.

Screenshots

Relevant log files
None - IKE Child SA Negotiation sometimes fails due to dead-peer and does not attempt to re-negotiate even after receiving no responses to DPD requests.

Additional context
I have reviewed the IPsec plugin code (core/src/etc/inc/plugins.inc.d/ipsec.inc) and believe the problematic code is located at lines 1545-1551.

Specifically:

I believe that all references to "start" should be corrected to "restart". I am not sure if there are additional dependencies with this same error.

Environment
OPNsense 24.1.5_3-amd64
FreeBSD 13.2-RELEASE-p11
OpenSSL 3.0.13
Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz (2 cores, 4 threads)

[AdSchellevis]

The upstream documentation about this is a bit inconsistent on this topic https://wiki.strongswan.org/projects/strongswan/wiki/Fromipsecconf -> https://docs.strongswan.org/docs/5.9/swanctl/swanctlConf.html, according to the migration guide it should be start, the manual doesn't mention start at all.

Just to be sure, to rule our both actually do the same, did you configure a dpd_delay on the connection itself. When set to the default there is no dpd if I'm not mistaken.

[AdSchellevis]

When looking at swanctl --list-conns | grep dpd, both restart and start seem to be presented as start on my end after modifying /usr/local/etc/swanctl/swanctl.conf manually and restarting the service (/usr/local/etc/rc.d/strongswan onerestart).

[KYLE-HILL]

Good morning,

Thank you for looking into my issue. I have configured a dpd_delay of 30 seconds for the connection on both ends. Hmmm - Thats very interesting regarding the start v. restart inconsistency in the strongSwan docs. I looked at the 5.9 docs and only saw "restart" listed as an option hence the initial bug report.

My phase 2 and associated SPD is dying for some reason and not being re-negotiated after the peer dies. I thought I had it narrowed down to DPD not re-negotiating, but it looks like I might need to dig into this some more and see if it happens during re-key or randomly.

Here is my complete setup for "fw01". "fw02" is also running the same version of OPNsense and configured the same. I do have FQDNs configured which I know are broken in strongSwan 5.9 with VTI mode. I am currently using Policy mode.

[AdSchellevis]

It might help to increase the log levels a bit and check for events around your issue, the packet capture is also a useful tool to inspect if anything is being exchanged between the peers.

[gongoscho]

Security Recommendations
It is strongly advised to use start_action = trap in site-to-site setups to make sure that the kernel tells the charon daemon to establish a CHILD_SA when there is no SA for a security policy.

Tunnel Shunting

[KYLE-HILL]

@gongoscho - Thanks for the recommendation.
@AdSchellevis - During troubleshooting I changed the proposals to aes128gcm16-sha256-ecp521 & aes128gcm16-ecp521 and have not been having any issues with the peer dropping or with re-keying. I am going to close this out as resolved since the changed propsal appears to have resolved the issue. Thank you for your help and insight. - Kyle