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