Archive > 20.1 Legacy Series
IPSec Dead Peer Detection problem
(1/1)
c-mu:
Hi,
I have a problem with IPSec and DPD. If I change an IPSec OR OpenVPN Server Config, it could happen, that a few IPSec Tunnels went down. But not all.
The Problem there is: the remote Site still thinks, that the tunnel is alive. I have to restart the Strongswan Service on all affected remote Sites. I've got 7 IPsec tunnels and 3-4 of them have that issue.
I played around with the DPD settings, like: 5 seconds, 3 retrys and as Action "Restart the tunnel". But even if I wait a minute, it does not happen. I also added a few "ping address" entries into the Phase2.
It's not a 20.1 related issue, it was also on 19.1.x
Any ideas what is going wrong? Thank you.
Edit: all Remote Sites running 20.1 or 19.1.
Snoopy325:
I have the same problem :-(
c-mu:
Yep. Meanwhile all my Servers running the latest 20.1.1 Version and yesterday evening, I changed some openvpn and Firewall Serversettings and a few IPSec tunnels went down. I connected then via public IP to the management interfaces and they still showed an online tunnel - which was wrong. I had to manually restart the strongswan service on the affected remote sites.
Snoopy325:
Does nobody have a solution for this?
I need about 90 site to site tunnel.
pmladenov:
I have the exact same problem with 20.7.5 and here's what I've found:
https://wiki.strongswan.org/projects/strongswan/wiki/connsection
--- Quote ---dpdaction = 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.
--- End quote ---
And from https://wiki.strongswan.org/projects/strongswan/wiki/Retransmission
--- Quote ---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
--- End quote ---
And guess what I have in the config:
--- Quote ---root@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
--- End quote ---
DPD is incorrectly configured here with ikev2 it should use:
--- 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
--- End quote ---
Regards,
Plamen
Navigation
[0] Message Index
Go to full version