[strongSwan] Multiple chiled SA's

Tobias Brunner tobias at strongswan.org
Mon Aug 5 11:49:31 CEST 2013

Hi Brian,

> From this log
> it appears to me that after re-making the IKE_SA and child SA (because
> they should be deleted when re-auth is done), it then generates a 2nd
> CHILD_SA {3} when it had {8} already?

This is due to a race condition between auto=route and reauth=yes.
Reauthentication, as opposed to rekeying, recreates the whole IKE_SA and
all established CHILD_SA, that is, the existing SAs are torn down and
then recreated from scratch.  If there is traffic matching the installed
IPsec trap policies during the downtime a second CHILD_SA gets triggered
as can be seen in the log:

> charon: 14[IKE] reauthenticating IKE_SA server1[1]
> charon: 14[IKE] deleting IKE_SA server1[1] between
> ...
> charon: 10[IKE] restarting CHILD_SA server1
> ...

No SAs at this point, so traffic triggers another CHILD_SA.

> charon: 03[KNL] creating acquire job for policy[gre]
>  ===[gre] with reqid {3}
> ...
> charon: 11[IKE] CHILD_SA server1{8} established with SPIs c5de30e9_i
> c83d99c0_o and TS ===
> ...
> charon: 09[IKE] CHILD_SA server1{3} established with SPIs c5305aff_i
> ca8e128e_o and TS ===

There is currently no check if a task to create the same (or a
congruent) CHILD_SA is queued.  If you don't really need
reauthentication the easiest fix is to use rekeying (reauth=no).  You
could also try to disable rekeying altogether (rekey=no) and just let
the SAs expire (they get recreated on traffic due to auto=route, but
that might have to be set on both sides then).


More information about the Users mailing list