Hi Martin, Thanks for the speedy reply.
Using auto=route doesn't quite alleviate your concerns about conflicts when both sides initiate simultaneously, because the 'route' trigger can happen on both sides simultaneously as well. Also, if I understand correctly, auto=route causes packet loss during the initial burst, and a user that sends infrequent bursts may have a bad time. As a suggested approach, if both peers initiate simultaneously, we should shoot for having them 'eventually' agree on a single IKE_SA even if it does take more than one round. Perhaps replacing duplicates on the initiator is a step in the right direction. In the mean time, it seems that I can simulate my desired behavior by periodically calling hydra->kernel_interface->acquire() even if no packets arrive. This code seems to be fairly well protected against multiple simultaneous calls. What do you think? Thanks, Noam On Wed, Nov 26, 2014 at 4:20 PM, Martin Willi <[email protected]> wrote: > 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
