[strongSwan-dev] Auto-recovery

[Noam Lampert]

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 <martin at strongswan.org> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20141126/4be982b4/attachment.html>