DPD is not working properly with IKEv2

Started by pmladenov, February 08, 2021, 09:50:58 PM

Previous topic - Next topic
Hello,

I'm running OpnSense 20.7.5

I've configured Site-to-Site IPSec tunnel with IKEv2 and DPD with 2 seconds interval, 5 retries and action=restart tunnel.

My ipsec.config:

Quoteroot@OPNsense:/tmp # cat /usr/local/etc/ipsec.conf
# This file is automatically generated. Do not edit
config setup
  uniqueids = yes

conn pass
  right=127.0.0.1 # so this connection does not get used for other purposes
  leftsubnet=10.30.0.0/16
  rightsubnet=10.30.0.0/16
  type=passthrough
  auto=route

conn con1
  aggressive = no
  fragmentation = yes
  keyexchange = ikev2
  mobike = yes
  reauth = yes
  rekey = yes
  forceencaps = no
  installpolicy = yes
  type = tunnel
  dpdaction = restart
  dpddelay = 2s
  dpdtimeout = 12s



Based on
https://wiki.strongswan.org/projects/strongswan/wiki/connsection

Quotedpdaction = none | clear | hold | restart

controls the use of the Dead Peer Detection protocol (DPD, RFC 3706) where R_U_THERE notification messages
(IKEv1) or empty INFORMATIONAL messages (IKEv2) are periodically sent in order to check the liveliness of the
IPsec peer. The values clear, hold, and restart all activate DPD and determine the action to perform on a timeout.
With clear the connection is closed with no further actions taken. hold installs a trap policy, which will catch
matching traffic and tries to re-negotiate the connection on demand. restart will immediately trigger an attempt
to re-negotiate the connection. The default is none which disables the active sending of DPD messages.

dpddelay = 30s | <time>

defines the period time interval with which R_U_THERE messages/INFORMATIONAL exchanges are sent to the peer.
These are only sent if no other traffic is received. In IKEv2, a value of 0 sends no additional INFORMATIONAL
messages and uses only standard messages (such as those to rekey) to detect dead peers.

dpdtimeout = 150s | <time>

defines the timeout interval, after which all connections to a peer are deleted in case of inactivity.
This only applies to IKEv1, in IKEv2 the default retransmission timeout applies, as every exchange is used to
detect dead peers.

And from https://wiki.strongswan.org/projects/strongswan/wiki/Retransmission

Quote
retransmit_tries    Integer    5    Number of retransmissions to send before giving up
retransmit_timeout    Double    4.0    Timeout in seconds
retransmit_base    Double    1.8    Base of exponential backoff

Using the default values, packets are retransmitted as follows:
Retransmission    Formula    Relative timeout    Absolute timeout
1    4 * 1.8 ^ 0    4s    4s
2    4 * 1.8 ^ 1    7s    11s
3    4 * 1.8 ^ 2    13s    24s
4    4 * 1.8 ^ 3    23s    47s
5    4 * 1.8 ^ 4    42s    89s
giving up    4 * 1.8 ^ 5    76s    165s

Apparently that ipsec.conf configuration is not relevant for ikev2 and that's the reason why it takes so long to reset the tunnel (in my case ~90+ seconds)

Is there any easy way I can fix that one?
As stated in the comment section of /usr/local/etc/ipsec.conf
root@OPNsense:/tmp # cat /usr/local/etc/ipsec.conf
# This file is automatically generated. Do not edit

where should I make the modification (considering I'm not gonna use ikev1 and only ikev2 in that setup)

Regards,
Plamen

Sorry for finding this so late.

The workaround mentioned here still works for me.
https://github.com/opnsense/core/issues/3291#issuecomment-479827420

My current add on config looks like this:

root@opnsense01:~ # cat /usr/local/etc/strongswan.opnsense.d/strongswan.ikev2.conf
charon {
# See https://wiki.strongswan.org/issues/1216
    make_before_break = yes
# See https://github.com/opnsense/core/issues/3291
    retransmit_tries = 10
    retransmit_timeout = 2
    retransmit_base = 1
}
root@opnsense01:~ #