[strongSwan] "loosing" Security Associations

[John A. Sullivan III]

On Tue, 2013-07-02 at 11:24 +0200, Jozef Kutej wrote:
> Hello strongSwan users,
> 
> our current configuration is host-to-host tunneled ipsec between 9 hosts 
> using certificates to authenticate. Here is current configuration (srv0):
> 
> ------ cut ------
> config setup
>        plutostart=no
> 
> conn srv1
>        left=21.23.23.24
>        leftid=srv0 at ipsec.domain
>        leftcert=validad.pem
>        leftsubnet=10.0.64.1/23
>        right=8.19.20.2
>        rightid=srv1 at ipsec.domain
>        rightsubnet=10.0.200.4/32
>        keyexchange=ikev2
>        keyingtries=%forever
>        lifetime=24h
>        margintime=15m
>        auto=start
> conn srv2
>        left=21.23.23.24
>        leftid=srv0 at ipsec.domain
>        leftcert=validad.pem
>        leftsubnet=10.0.64.1/23
>        right=14.7.7.18
>        rightid=srv2 at ipsec.domain
>        rightsubnet=10.0.9.1/24
>        keyexchange=ikev2
>        keyingtries=%forever
>        lifetime=24h
>        margintime=15m
>        auto=start
> -> 6 more connections
> ------ cut ------
> 
>  From time to time it happens that suddenly there is no Security 
> Associations for one of the connections and until `ipsec reload` is 
> triggered it will never recover.
> 
> all there is in logs is:
> 
> Jul  1 17:20:55 srv0 charon: 02[NET] received packet: from 
> 14.7.7.18[4500] to 21.23.23.24[4500]
> Jul  1 17:20:55 srv0 charon: 02[ENC] parsed INFORMATIONAL request 2 [ D ]
> Jul  1 17:20:55 srv0 charon: 02[IKE] received DELETE for IKE_SA srv2[549]
> Jul  1 17:20:55 srv0 charon: 02[IKE] deleting IKE_SA srv2[549] between 
> 21.23.23.24[srv0 at ipsec.domain]...14.7.7.18[srv2 at ipsec.domain]
> Jul  1 17:20:55 srv0 charon: 02[IKE] IKE_SA deleted
> Jul  1 17:20:55 srv0 charon: 02[ENC] generating INFORMATIONAL response 2 [ ]
> Jul  1 17:20:55 srv0 charon: 02[NET] sending packet: from 
> 21.23.23.24[4500] to 14.7.7.18[4500]
> 
> the other side:
> 
> Jul  1 15:20:43 srv2 charon: 15[IKE] deleting IKE_SA srv0-v4[112] 
> between 14.7.7.18[srv2 at ipsec.domain]...21.23.23.24[srv0 at ipsec.domain]
> Jul  1 15:20:43 srv2 charon: 15[IKE] sending DELETE for IKE_SA srv0-v4[112]
> Jul  1 15:20:43 srv2 charon: 15[ENC] generating INFORMATIONAL request 2 
> [ D ]
> Jul  1 15:20:43 srv2 charon: 15[NET] sending packet: from 
> 14.7.7.18[4500] to 21.23.23.24[4500]
> Jul  1 15:20:47 srv2 charon: 10[NET] sending packet: from 
> 14.7.7.18[4500] to 21.23.23.24[4500]
> Jul  1 15:20:54 srv2 charon: 12[IKE] retransmit 2 of request with 
> message ID 2
> Jul  1 15:20:54 srv2 charon: 12[NET] sending packet: from 
> 14.7.7.18[4500] to 21.23.23.24[4500]
> Jul  1 15:21:07 srv2 charon: 05[IKE] retransmit 3 of request with 
> message ID 2
> Jul  1 15:21:07 srv2 charon: 05[NET] sending packet: from 
> 14.7.7.18[4500] to 21.23.23.24[4500]
> Jul  1 15:21:13 srv2 charon: 09[IKE] destroying IKE_SA in state DELETING 
> without notification
> 
> One observation is that this trouble happens only by host which network 
> connection is not reliable, which has packet loss under heavy traffic. 
> Other hosts do the same -> send delete IKE_SA but then, right away new 
> initiating IKE_SA happens. So it may be that srv2 sends delete IKE_SA, 
> srv0 accepts it, perform delete, sends response back which is dropped 
> and never retransmitted and it stays that way and SA is never ever 
> renegotiated.
> 
> Is there a way to prevent this? What we would like to have is persistent 
> ipsec between always-on servers.
<snip>
This looks like exactly the problem we're having and I've not found a
solution.  I do not think the problem is the network connection - John