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

Pisano, Stephen G (Stephen) Stephen.Pisano at alcatel-lucent.com
Fri Mar 11 12:11:59 CET 2011

Hi Martin:


Eduardo will follow-up on the monotonic time source lead you provided, but I have a question regarding your second comment.

We thought it was possible (and we think we have it configured this way) to have strongSwan try to establish its connections forever.  I assumed this should be the case even if there is a hard rekey timeout.  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?


>-----Original Message-----
>From: users-bounces+pisano=alcatel-lucent.com at lists.strongswan.org
>[mailto:users-bounces+pisano=alcatel-lucent.com at lists.strongswan.org] On
>Behalf Of Martin Willi
>Sent: Friday, March 11, 2011 2:57 AM
>To: Torres, Eduardo M (Eduardo)
>Cc: users at lists.strongswan.org
>Subject: Re: [strongSwan] IKE_SA gets deleted with no recovery after NTP
>Hi Eduardo,
>> We rely on the system time to be correct.
>Depends on how strongSwan is built. If your system provides a monotonic
>time source and compatible pthread_condvars, we use it. This is checked
>during ./configure, checking for
>  pthread_condattr_setclock(&attr, CLOCK_MONOTONIC)
>or alternatively for
>  pthread_cond_timedwait_monotonic
>If such condvars are available, we use always increasing never jumping
>time source, and system time changes shouldn't affect rekeying or other
>timed behavior.
>> after the rekey, Strong Swan deletes the IKE_SA but does not re-try to
>> create the IKE_SA
>If you don't have such a condvar, large time shifts may trigger soft and
>hard timeouts simultaneously, resulting in a hard timeout.
>Users mailing list
>Users at lists.strongswan.org

More information about the Users mailing list