[strongSwan] Broken CHILD_SA following IKE_SA re-auth with FortiGate remote

Tobias Brunner tobias at strongswan.org
Mon Aug 29 14:23:56 CEST 2016

Hi Tore,

> There was one thing you mentioned above that gave me some pause though:
> Ā«some heuristics might have to be used to avoid destroying the old SAs
> as duplicatesĀ»
> Could you elaborate on how this might be a problem?
> If I understand correctly: if make-before-break reauth is being
> performed, and strongSwan has successfully establisehed replacement
> IKE and Child SAs, then it shouldn't be any problem with destroying the
> old and duplicate/superfluous IKE SA (and its associated Child SAs)?
> Why would you want to avoid that from happening - isn't getting rid of
> the old SAs precisely the point of reauthenticating?

Yes, but the initiator of the new SA should do so.   The responder
checks for duplicates (uniqueids=yes, identities matching) before the
CHILD_SAs are fully established (or attributes are assigned).  So that
might interrupt traffic and could interfere with the reauthentication
process on the client (if the old SA is deleted while the new one is not
fully established yet - i.e. the IKE_AUTH response has not been received
- it might abort the reauth).  So to avoid unintentionally deleting the
old SA as duplicate strongSwan, in addition to the identities, compares
the remote IP and port and assumes a reauthentication if they match (a
DELETE is then scheduled 10 seconds later, just in case the initiator
doesn't delete the old SA after the new one was established).


More information about the Users mailing list