<div dir="ltr">Hi Martin,<div><br></div><div>Thanks for the speedy reply.</div><div><br></div><div>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.</div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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?<br></div><div><br></div><div>Thanks,</div><div><br></div><div>Noam</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 26, 2014 at 4:20 PM, Martin Willi <span dir="ltr"><<a href="mailto:martin@strongswan.org" target="_blank">martin@strongswan.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Noam,<br>
<br>
> [...] I would like to my VPN to continue trying to establish so that if<br>
<span class="">> the environment error is fixed, the tunnel will re-establish.<br>
><br>
> It seems that auto=start doesn't have this behavior, and if the peer<br>
> doesn't respond, strongswan eventually gives up and enters a passive state.<br>
<br>
</span>While there is the keyingtries parameter in ipsec.conf that allows you<br>
to retry indefinitely, unfortunately that is no guarantee that your<br>
tunnel comes and stays up. There are just to many protocol failures we<br>
currently can't catch to keep a connection up.<br>
<br>
Instead one could add some kind of monitoring functionality, either<br>
internal or as external process, trying to detect SA failures and<br>
reacting accordingly. However, this is not trivial at all; a peer may<br>
close an IKE_SA actively to reauthenticate it. Should we then retrigger<br>
that SA, with a risk that the peer at the same time does the same? This<br>
will result in another conflict, where one of the peers probably deletes<br>
the redundant SA initiated by the other, just to trigger another "down"<br>
event and start over the whole game.<br>
<br>
An approach I recommend and that works good in practice is using<br>
auto=route for connections you want to have "always up". Should the SA<br>
fail for whatever reason, the kernel will trigger the SA to come up<br>
again. This should work rather reliably.<br>
<br>
For the next release, we also have some changes regarding reqid<br>
allocation in the pipeline [1]. This should prevent SA conflicts when<br>
the same connection gets initiated by both ends simultaneously, and<br>
should avoid some of these evil race conditions.<br>
<span class=""><br>
> Shouldn't an IKE_SA establish with UNIQUE_REPLACE cause the dupliate<br>
> IKE_SAs to get dropped also on the initiator side?<br>
<br>
</span>Probably it should, but it currently won't. In practice you most likely<br>
create conflicting policies when initiating actively, letting the SA<br>
fail anyway. The uniqueness check is mostly for responders to avoid<br>
multiple SAs with the same peer; but we probably should consider<br>
replacing duplicates as initiator as well.<br>
<br>
Regards<br>
Martin<br>
<br>
[1]<a href="http://git.strongswan.org/?p=strongswan.git;a=shortlog;h=refs/heads/reqid-alloc" target="_blank">http://git.strongswan.org/?p=strongswan.git;a=shortlog;h=refs/heads/reqid-alloc</a><br>
<br>
</blockquote></div><br></div>