[strongSwan-dev] ipsec rereadsecrets restarts tunnels

[James Hulka]

Hello Tobias,

thank you for the clarification and the patches. Please see my comments
inline.

Best Regards,

James

On 03/01/2013 05:16 PM, Tobias Brunner wrote:
> Hi James,
> 
>> This has the effect that currently established tunnels are deleted and
>> re-initiated
> 
> Hm, how so?  There is no code that would cause the daemon to terminate
> any established connections or establish new ones on a simple call to
> ipsec rereadsecrets.

>> loading secrets from '/etc/ipsec.secrets'
>>   loaded RSA private key from '/etc/ipsec.d/private/a.pem'
>>
>> received stroke: delete connection 'a_to_b'
>> deleted connection 'a_to_b'
>>
>> received stroke: add connection 'a_to_b'
>>   loaded RSA public key for "a.a.a.a" from '/etc/ipsec.d/public/a.pub'
>>   loaded RSA public key for "b.b.b.b" from '/etc/ipsec.d/public/b.pub'
>> added configuration 'a_to_b'
>> received stroke: initiate 'a_to_b'
> 
> It seems there is a rereadsecret and a reload/update happening at the
> same time (plus you seem to use auto=start).  What command(s) did you
> execute exactly?

I am running a ipsec reload after the ipsec rereadsecrets call.

>> I have a situation where I would like to load a second private key to be
>> used with a second interface w/o the tunnels on the first interface
>> being interrupted.
> 
> Existing tunnels should not be interrupted by ipsec rereadsecrets, but
> there is a race condition if the daemon tries to establish an SA (as
> initiator or responder) while secrets are concurrently loaded.  This is
> because secrets are first cleared and only then loaded again, so there
> is a short timeframe in which some of the secrets loaded earlier might
> not be available anymore.  I pushed two patches [1] that address this
> issue.  Let me know if they solve your problem.

With your patches + StrongSwan v5.0.2 the ipsec rereadsecrets + ipsec
reload behavior remains the same.

When I change the ipsec reload to ipsec update the already established
connection is not being affected by the update call and thus solves my
problem.

> Regards,
> Tobias
> 
> [1]
> http://git.strongswan.org/?p=strongswan.git;a=shortlog;h=refs/heads/fix-rereadsecrets
>