Issue #1312

Long "delete connection" when responder is suddenly off (i.e power or network failure)

Added by Jiri Zendulka over 6 years ago. Updated over 6 years ago.

Affected version:
No change required



I have following situation. An IPsec tunnel has been succesfully established beetwen two devices with strongswan (an initiator and a responder). When I turn off the responder and I stop/restart the initiator then initiator waiting for "deleting connection" for some time - I guess for responder's response which never comes because the responder is currently off. Is it possible reduce this time or disable waiting for "delete notification" response. I think that openswan does not wait for this message.



#1 Updated by Jiri Zendulka over 6 years ago

ipsec3: fd07:7::e5...fd07:7::ee IKEv2
ipsec3: local: [fd07:7::e5] uses pre-shared key authentication
ipsec3: remote: [fd07:7::ee] uses pre-shared key authentication
ipsec3: child: fd00:2::/64 === fd00:1::/64 TUNNEL
Security Associations (1 up, 0 connecting):
ipsec31: DELETING, fd07:7::e5[fd07:7::e5]...fd07:7::ee[fd07:7::ee]
ipsec31: IKEv2 SPIs: fe5843c80fde9389_i* 1d3684a76c78b90d_r
ipsec31: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
ipsec31: Tasks active: IKE_DELETE
ipsec3{1}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: ca7b34a9_i ca9c1d1c_o
ipsec3{1}: AES_CBC_128/HMAC_SHA1_96, 3016 bytes_i (29 pkts, 23s ago), 5408 bytes_o (52 pkts, 0s ago), rekeying in 42 minutes
ipsec3{1}: fd00:2::/64 === fd00:1::/64

#2 Updated by Noel Kuntze over 6 years ago

You can tune the retransmission settings and/or use DPD to drop tunnels to dead peers.
The default retransmission settings make charon wait for up to 76 seconds for a timeout.

From the man page about strongswan.conf

       Retransmission timeouts in the IKEv2 daemon charon  can  be  configured
       globally using the three keys listed below:

              charon.retransmit_base [1.8]
              charon.retransmit_timeout [4.0]
              charon.retransmit_tries [5]

       The following algorithm is used to calculate the timeout:

            relative timeout = retransmit_timeout * retransmit_base ^ (n-1)

       Where n is the current retransmission count.

       Using the default values, packets are retransmitted in:

       Retransmission   Relative Timeout   Absolute Timeout
       1                              4s                 4s
       2                              7s                11s
       3                             13s                24s
       4                             23s                47s
       5                             42s                89s
       giving up                     76s               165s

#3 Updated by Jiri Zendulka over 6 years ago

Hi Noel,

many thanks for your answer. But I guess that the charon.retransmit settings have an impact to all ikev2 messages so I am not sure if it is good way to tune timout of "ike delete" messages. I noticed that ikev1 does not have this issue/feature - there is no waiting for ike delete task. Is it possible to disable waiting for ike delete response? DPD is not suitable solution too because the timout is quite long. I use shell script to control ipsec tunnels and pending ike delete task is an issue for me - when I restarting/stopping ipsec tunnels I launch ipsec down "tunnelx" and then I check if all tunnels are down via stroke status "tunnelx" if they are down I kill stater deamon. The pending ike delete task blocks killing stater daemon...

#4 Updated by Tobias Brunner over 6 years ago

  • Status changed from New to Feedback

Try ipsec stroke down-nb <name>, which does not block and wait until the exchange completes/times out.

#5 Updated by Jiri Zendulka over 6 years ago

Hi Tobias,

thanks for your help. Stroke down-nb does not help in my case. I modified my shell script in the end. When I stop ipsec I kill charon even though there is some tunnel pending "deleting state".

#6 Updated by Tobias Brunner over 6 years ago

  • Category set to configuration
  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Resolution set to No change required

When the daemon terminates it does not wait for a response to the deletes it sends for all existing IKE_SAs. But I'm closing this as you apparently found a solution.

Also available in: Atom PDF