We are trying to establish a persistent VPN connection against a Juniper box. However there is some misconfiguration. When we start the StrongSwan service, the tunnel is up and all traffic go fine. But as soon as there is no traffic flow in a couple of seconds the connection is down and the service must be restarted. When we run an endless ping loop to the VPN destination IP address on background, the connection survive. We believe, it is some kind of keep-alive related problem. Does anyone see any possible configuration inconsistency?

Spec sheet - both sites agreed upon the following IPSec settings:

Phase 1 (Key Exchange):
Encryption {3DES, AES256}: AES256
Data Integrity {MD5,SHA1,SHA2}: SHA256
Diffie-Hellman {MD5,SHA1,SHA2}: 5
Renegotiate IKE SA {Seconds}: 86400

Phase 2 (Data Transport):
Encryption {3DES, AES256}: AES256
Data Integrity {MD5,SHA1,SHA2}: SHA256
PFS: Yes
Diffie-Hellman: 5
SA Life Time {Seconds}: 3600
IP Compression: No

Related configuration files follows.


config setup
  charondebug="ike 4, knl 4, cfg 4, net 4, esp 4, dmn 4,  mgr 4"
conn %default
conn otto-105-183
conn otto-100-34
conn otto-100-35
conn otto
  right=my_public_IP_address  ; redacted


charon {
    keep_alive = 20s
    crypto_test {
    host_resolver {
    leak_detective {
    processor {
        priority_threads {
    start-scripts {
    stop-scripts {
    tls {
    x509 {
  • Try to find out if that dpdtimeout value in the strongswan side is too high; as alternative, set both dpd timeouts on both sides to 30s. – Rui F Ribeiro Aug 12 '16 at 10:17
  • I have tried to change the parameter dpdtimeout=30s however to no avail. Do you think that some information (and which?) from the log file could help? Thanks, David – zBit zBit Aug 16 '16 at 14:11
  • Have you changed both sides? It is no use changing only one side – Rui F Ribeiro Aug 16 '16 at 16:07
  • Eventually, the IPSec tunnel is up and stable for some time so probably DPD really did the trick! Thanks! – zBit zBit Aug 18 '16 at 8:31
  • Excellent, I added an answer – Rui F Ribeiro Aug 18 '16 at 19:48

The VPN going down and falling seems to be a (frequent) problem of timeout negotiation.

I advise changing the dpd timeout on the equipments of both sides of the VPN to 30 seconds. Both have to have the same value.

In the Linux side it is enough to define


In some situations when dealing with 3rd party hardware, from my experience it seems to be more successful choosing lower dead peer timeouts.

From Understanding Dead Peer Detection

Dead peer detection (DPD) is a method that network devices use to verify the current existence and availability of other peer devices.
A device performs DPD verification by sending encrypted IKE Phase 1 notification payloads (R-U-THERE messages) to a peer and waiting for DPD acknowledgements (R-U-THERE-ACK messages) from the peer. The device sends an R-U-THERE message only if it has not received any traffic from the peer during a specified DPD interval. If the device receives an R-U-THERE-ACK message from the peer during this interval, it considers the peer alive. If the device receives traffic on the tunnel from the peer, it resets its R-U-THERE message counter for that tunnel, thus starting a new interval. If the device does not receive an R-U-THERE-ACK message during the interval, it considers the peer dead.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.