[strongSwan] IKE_SA gets deleted with no recovery after NTP update

[Pisano, Stephen G (Stephen)]

Hi Martin:

I did not really follow this part of your response:

>The initiator of the delete
>currently does not enforce the close action for tunnels it deletes. And
>this does not make a lot of sense, as it shouldn't happen in a properly
>configured setup.

I don't understand the difference between a "delete" and a "close", and I don't know what you mean when you say, "And this does not make a lot of sense, as it shouldn't happen in a properly configured setup.".

Btw, we have dpdAction set to 'restart'.

The behavior we want is for strongSwan to keep trying to establish all of its configured tunnels, even if we don't have monotonic clock support, and an NTP sync causes the IKE_SA to be deleted.  

I think you are saying this behavior is not currently possible, but I am not certain.

If this behavior is possible, can you provide guidance on what the configuration should be to yield this behavior?  Note, we only have control over our end of the tunnel.  The remote end is not necessarily a strongSwan implementation.

If this behavior is not possible, then we need some way to detect that this particular scenario has occurred, for example, through up/down script or whatever means, so that we can take some recovery action.  Can you let us know how we could possible detect that this scenario has occurred (i.e., that the IKE SA has been deleted and strongSwan will not try to restart it)?

Thanks,
Stephen 

>-----Original Message-----
>From: Martin Willi [mailto:martin at strongswan.org]
>Sent: Friday, March 11, 2011 6:29 AM
>To: Pisano, Stephen G (Stephen)
>Cc: Torres, Eduardo M (Eduardo); users at lists.strongswan.org
>Subject: RE: [strongSwan] IKE_SA gets deleted with no recovery after NTP
>update
>
>
>> Further, I assumed regardless of what happens (short of
>> something catastrophic/fatal, like the unavailability of a critical
>> system resource), strongSwan should always keep trying, forever.  Is
>> this an incorrect assumption?
>
>Depending on your configuration, it should in most cases keep the tunnel
>up. What you have seen here, though, is a special case: the IKE_SA
>rekeying could not refresh the tunnel in time before the hard lifetime
>of the SA is reached. And as we really want to enforce the lifetime
>limit, the tunnel gets closed. DPD does not trigger, as the peer
>actually responds.
>
>A responder could enforce tunnel re-establishment using a close-action
>(configured as dpd_action in ipsec.conf). The initiator of the delete
>currently does not enforce the close action for tunnels it deletes. And
>this does not make a lot of sense, as it shouldn't happen in a properly
>configured setup.
>
>Regards
>Martin