strongSwan

Connections:
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):
ipsec3¹: DELETING, fd07:7::e5[fd07:7::e5]...fd07:7::ee[fd07:7::ee]
ipsec3¹: IKEv2 SPIs: fe5843c80fde9389_i* 1d3684a76c78b90d_r
ipsec3¹: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
ipsec3¹: 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

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

IKEv2 RETRANSMISSION
       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

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...

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".