On Wed, 2017-02-15 at 10:56 -0500, Tom Rymes wrote:
> Michael, et. al.,
> 
> I don't know if my message will get through to the mailing list, but here's my
> $0.02:

It will if you subscribe to that list.

> This all started with a request I made about setting the Strongswan "auto"
> feature to "route" instead of "start" for site-to-site tunnels. This setting
> change does as you describe, which is to leave a tunnel "triggered" when it is
> created or StrongSwan is started, then it is automatically established when
> traffic flows.
> 
> This has benefits for resources and entropy, I suppose, but those are not of a
> significant benefit in my view. If you do implement a "timeout" setting for
> tunnels to disconnect if there is no traffic, I would personally want to
> disable that feature, though I can see how some might want to use it. HOWEVER:
> the auto=route setting is what is recommended by StrongSwan, in part for
> security reasons (also handled by IPFire's default iptables rules).

At the moment that is not configurable. I think this is essentially the biggest
benefit of all of this that not all connections are active all the time.

Do you set your connections to auto=route in all branches or just in HQ?

> Our experience is that using the auto=route setting GREATLY improves the
> robustness of the tunnels when it come to re-establishing them after something
> goes wrong. If a tunnel drops due to a network issue and that issue is not
> resolved before Strongswan times out connecting that tunnel, that tunnel stays
> down until manually brought back up when auto=start. If auto=route, though,
> that tunnel will be re-established more reliably in such a scenario. Changing
> that setting has substantially improved our tunnel reliability.
> 
> Thanks for your attention to this, I know all of your time is in short supply!
> I will do my utmost to try and test the changes.

-Michael

> 
> Tom
> 
> > 
> > On Feb 15, 2017, at 9:54 AM, Michael Tremer <michael.tremer(a)ipfire.org>
> > wrote:
> > 
> > Hello guys,
> > 
> > sorry for my absence in the last few days and weeks. This list has been more
> > or
> > less read-only for me and I would like to chance this. I would like to see
> > more
> > people involved in this project and take part in what we do here. So it is
> > important that everyone is in the know about what is going on.
> > 
> > This morning I worked on a small feature which is probably quite
> > interesting:
> > On-demand IPsec VPN tunnels.
> > 
> > What does it do? It essentially installs triggers in the kernel instead of
> > bringing up the VPN tunnel right away. As soon as the kernel is receiving a
> > packet that is supposed to be sent through that VPN, it will ask strongSwan
> > to
> > bring up the tunnel and send the packet.
> > 
> > When the VPN tunnel has not transferred any packets for 15 minutes, it will
> > terminate it and restart it when it is needed again.
> > 
> > Why is this such a great feature? It is simple, but in scenarios with many
> > VPN
> > tunnels (e.g. headquarters and many branch offices) it does not always make
> > sense to keep all tunnels up all of the time. This feature will shut down
> > any
> > tunnels that are not needed and keep resources free.
> > 
> > This is probably not much, but we have seen machines with only few entropy
> > and
> > we have seen IPsec becoming unstable then.
> > 
> > The web user interface shows the status if a tunnel is idle or connected.
> > 
> > Patches are in next:
> > 
> >  http://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=dcb406cc675c42f9add4
> > a41c8a1e07eea7c3ab08
> >  http://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=1ee1666ee45268db405a
> > 66b8ec05501c718e7702
> >  http://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=8057ab15b9efeecf8eca
> > 7ad4ebba170f141bd3de
> > 
> > It would be cool if you all could have a look at them, test them, maybe
> > complete
> > translations for any languages that you speak, etc.
> > 
> > I am not sure if this will cause some problems with some applications that
> > rely
> > on fast establishing of connections.
> > 
> > Looking forward to hearing your feedback!
> > 
> > Best,
> > -Michael