[strongSwan] Multiple chiled SA's

[Tobias Brunner]

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
> 1.1.1.1[1.1.1.1]...2.2.2.2[2.2.2.2]
> ...
> 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 10.220.0.53/32[gre]
>  === 10.220.0.54/32[gre] with reqid {3}
> ...
> charon: 11[IKE] CHILD_SA server1{8} established with SPIs c5de30e9_i
> c83d99c0_o and TS 10.220.0.53/32 === 10.220.0.54/32
> ...
> charon: 09[IKE] CHILD_SA server1{3} established with SPIs c5305aff_i
> ca8e128e_o and TS 10.220.0.53/32 === 10.220.0.54/32

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

Regards,
Tobias