[strongSwan] MacOS: IKEv1 fails after wakeup

[Tobias Brunner]

Hi Harald,

> If I got you correctly, then dpdtimeout affects the lifetime
> of the IKE_SA. Using "dpdaction = clear" the IKE_SA is dropped
> 150s (by default) after the last notification package was
> received. Is this correct?

Yes, if there hasn't been any inbound traffic (IKE or ESP) within the
configured time frame the SA is closed.

> Mar 11 07:27:24 srvl047 ipsec[11514]: 02[NET] received packet: from 10.0.0.13[52555] to 10.0.0.17[4500]
> ...
> Mar 11 07:27:24 srvl047 charon: 02[NET] received packet: from 10.0.0.13[52555] to 10.0.0.17[4500]

Just as a side note, you might want to adjust your logger/syslog
settings to avoid the duplicate log messages.

> How comes that destroying the IKE_SA works, even though strongswan
> on the left side has lost the IKE_SA (following your description)?

The client deletes the new SA (id 65) that it failed to establish, not
the old one.  The log does only show the reconnection attempt so it's
not clear whether the old SA was still there or not.  You configured
dpdtimeout=500s, so how long was the client away?  And do you see the
DPDs and the deletion of the previous SA in the log?

One potential issue I hadn't considered so far is that while the client
is asleep the mapping on the NAT router might time out (it probably does
not send keepalives while asleep).  So when it reconnects it will do so
from different source ports from the server's point of view.  Due to
that the reauthentication detection will not recognize the new SA as
reauthentication attempt and therefore not migrate the previous virtual
IP.  So you'd end up in the same situation as before (i.e. the traffic
selectors don't match and the CHILD_SA can't be established).  Try to
compare the client's source ports to see if that's what happens here.

Regards,
Tobias