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@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