IKEV1: lost child_sa after ike_sa reauth about strongswan HOT 5 CLOSED

Everything workes fine with IKEV2.

Please don't use IKEv1 between two instances of strongSwan and you can use IKEv2.

from strongswan.

Everything workes fine with IKEV2.

Please don't use IKEv1 between two instances of strongSwan and you can use IKEv2.

I have to use IKEv1, primarly due to some service providers providing IKEv1 only peers.

from strongswan.

Then use it with them but not between strongSwan hosts.

Anyway, this seems to be some collision (both initiating reauths). Probably would happen more rarely if you used longer reauth times (gives the peers more chance to randomize the actual time they start it).

from strongswan.

Thanks a lot, I will try randomize the reauth time.

from strongswan.

I'm seeing something very similar to this between strongswan (initiator) and a barracuda firewall.

It also seems similar to this: https://wiki.strongswan.org/issues/3279

I don't think it's a race, because it happens with rekey_time set to 4h and 10h.

IKE_SA ikev1-psk-xauth[3] established between [...]
scheduling reauthentication in 35704s
maximum IKE_SA lifetime 39304s

35704s later:

IKE_SA ikev1-psk-xauth[4] established between [...]
scheduling reauthentication in 32916s
maximum IKE_SA lifetime 36516s

The connection works fine here, until 39304s after the first message when:

deleting IKE_SA ikev1-psk-xauth[3] between [...]
sending DELETE for IKE_SA ikev1-psk-xauth[3]

At this point I stop receiving packets from the peer. The SAs looks correct, and packets keep going out, but none come in.

A manual or scheduled rekey of the child SA restores the connection.

Edit: I should mention that I'm a little out of date. My distro (nixos) still has 5.8.1, so I'll attempt to upgrade and test again.

Edit: tested with 5.9.4 and the behaviour seems to be the same.

from strongswan.