[strongSwan] Reporting Issue:Old CHILD_SA not getting cleared

[Tobias Brunner]

Hi Anurag,

> 1)      We are using StrongSwan charon [Linux strongSwan 4.3.1]

Just let me tell you that we don't really like to support such old
releases.  It would great if you could try if this issue is still
present in 4.6.2.

> 3)      After around 600 sec. from the start, IKE_SA re-keying
> starts, but just before that we observe that an INFORMATIONAL message
> (with Next Payload: Delete) is sent from NODE A to NODE B. Is this
> expected even before the IKE_SA re-keying starts? Moreover NODE B
> responds back with an INFORMATIONAL message (with Next Payload:
> None). This is expected only when IKE_SA re-keying happens and old
> IKE_SA's delete message is sent.

Well, my guess is (without config it's hard to tell) that you have set
reauth=yes (which is the default) in your config.  Then this is
perfectly normal.  The previous IKE_SA is deleted and the new one is
established from scratch.  Setting reauth=no will cause charon to do a
regular rekeying.

> 4)      After the IKE_SA re-keying is over and new IKE_SA is created,
> we observe that 2 new CHILD_SA's are created even though before the
> re-keying period the IKE_SA had only 1 CHILD_SA. Now both these
> CHILD_SAs work independently and re-keying independently. So after
> the end of 1st IKE_SA re-keying we have 2 CHILD_SAs even though we
> started with 1. The output of setkey -D also confirms the same.

This might be a bug with reauthentication in 4.3.1.  Try a newer release
to verify if that's the case.

> This issue is not observed when both end of the tunnel, i.e., NODE A
> and NODE B have StrongSwan charon. We suspect that this could be an
> interoperability issue. Can you please help us in debugging this
> issue?

That's interesting, but it's hard to tell, without logs, what exactly
the differences between both of these cases are.  Comparing the logs
might give you some clue why it's not an issue between two hosts running
charon.

Regards,
Tobias