[strongSwan] 102x102 Host2Host tunnels - failure to reestablish some of them after network outage

Jiri Horky jiri.horky at gmail.com
Tue Jul 8 14:53:27 CEST 2014


Hi Martin,

thank you very much for the prompt response! I will follow your advice.

I would suggest to add this to some "FAQ" section, as this is probably
something others might be looking for and which was not obvious from
config file documentation (at least for me). Also, the side effect that
unencrypted traffic is never sent out, is actually a great benefit which
I was about to accomplish using iptables.

The only downside of this setup is that it is rather hard to decide
whether the tunnel is down, because there is no communication and it
would fire up on demand, or, because there is some error preventing the
tunnels to come up. We will probably add some "ping" to our monitoring
probes to keep the tunnels up all the time.

Cheers
Jiri Horky

On 07/08/2014 10:03 AM, Martin Willi wrote:
> Jiri,
>
>> Our requirement is to keep retrying the tunnel no matter what happens,
>> so I ended up with config like below for each host.
>> It seems that strongswan just stopped trying to connect to
>> some of the nodes (the failed "tunnels" are between different nodes, the
>> distribution seems to be random). I am out of ideas why strongswan gave
>> up trying and how to force real "forever retry".
>>         keyingtries=%forever
>>         dpdaction=restart
>>         closeaction=restart
>>         auto=start
> Even with such a configuration, there is no guarantee that your tunnel
> comes up. strongSwan gives up tunnel negotiation if it fails with a
> permanent error.
>
> To realize always-up tunnels, I recommend to use auto=route for your
> connections. This installs trap policies, and negotiates tunnels on
> demand. The kernel ensures that no matching plain traffic leaves your
> box, but instead it triggers a new tunnel should one fail for whatever
> reason.
>
> Regards
> Martin
>
>



More information about the Users mailing list