[strongSwan] Problem with rekey collisions

Martin Willi martin at strongswan.org
Tue Jan 20 15:23:41 CET 2015

Hi Andreas,

> Now my problem is that tunnels between devices break every few days. The log
> states that strongSwan detects a CHILD_REKEY collision, then it resolves the
> collision, but no traffic is going through.

> I noticed that after a rekey collision, some iptables rules were gone. I
> still have to verify this in the production system.

Most likely we falsely invoke the updown script with a "down" event for
that rekey collision, as that CHILD_SA gets deleted (but actually is
still up with the "winning" instance). Probably we can fix that, but I
don't know how trivial it is.

> RETURN     all  --         policy match dir in pol ipsec reqid 1 proto 50
> MARK       all  --         policy match dir out pol ipsec reqid 1 proto 50 MARK set 0x32

Seems that there are some complex firewall rules involved, not sure if
that is provided by your IPFire distribution or if these are your custom

As a work-around, you could consider using static policy matching IPsec
rules (not for specific subnets) instead of those installed with updown.
But I really don't know if that works for your specific rules.

> 1.) Is there any way to check wether rekey time randomization really works
> as it should?

Given that they are triggered randomly, I'd guess that works as

> 2.) Could you tell me why I am getting CHILD_REKEY collisions every few
> days? Is that to be expected?

Depends on your rekey configuration, latencies etc. Not unlikely that
these can happen, especially if you rekey every 40 minutes. You might
consider adjusting your rekey interval, margin and fuzz to reduce
collision probability.

Also you can use a shorter rekey time on one end, so rekeying is
guaranteed to get initiated by the same end only. This should make it
impossible that a collision happens if the options are chosen

> 3.) Any idea why the iptables rules get changed after rekey collision?

As said, most likely because we invoke that updown hook once too often
in that specific collision case.


More information about the Users mailing list