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 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. Regards, Tobias [1] http://git.strongswan.org/?p=strongswan.git;a=shortlog;h=refs/heads/fix-rereadsecrets _______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
