[strongSwan-dev] Auto-recovery

Martin Willi martin at strongswan.org
Wed Nov 26 15:20:17 CET 2014

Hello Noam,

> [...] I would like to my VPN to continue trying to establish so that if
> the environment error is fixed, the tunnel will re-establish.
> It seems that auto=start doesn't have this behavior, and if the peer
> doesn't respond, strongswan eventually gives up and enters a passive state.

While there is the keyingtries parameter in ipsec.conf that allows you
to retry indefinitely, unfortunately that is no guarantee that your
tunnel comes and stays up. There are just to many protocol failures we
currently can't catch to keep a connection up.

Instead one could add some kind of monitoring functionality, either
internal or as external process, trying to detect SA failures and
reacting accordingly. However, this is not trivial at all; a peer may
close an IKE_SA actively to reauthenticate it. Should we then retrigger
that SA, with a risk that the peer at the same time does the same? This
will result in another conflict, where one of the peers probably deletes
the redundant SA initiated by the other, just to trigger another "down"
event and start over the whole game.

An approach I recommend and that works good in practice is using
auto=route for connections you want to have "always up". Should the SA
fail for whatever reason, the kernel will trigger the SA to come up
again. This should work rather reliably.

For the next release, we also have some changes regarding reqid
allocation in the pipeline [1]. This should prevent SA conflicts when
the same connection gets initiated by both ends simultaneously, and
should avoid some of these evil race conditions.

> Shouldn't an IKE_SA establish with UNIQUE_REPLACE cause the dupliate
> IKE_SAs to get dropped also on the initiator side?

Probably it should, but it currently won't. In practice you most likely
create conflicting policies when initiating actively, letting the SA
fail anyway. The uniqueness check is mostly for responders to avoid
multiple SAs with the same peer; but we probably should consider
replacing duplicates as initiator as well.



More information about the Dev mailing list