From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: On-Demand IPsec VPN Date: Wed, 15 Feb 2017 16:09:28 +0000 Message-ID: <1487174968.24657.174.camel@ipfire.org> In-Reply-To: <762FB15B-0D41-4D22-9284-90C2BEDC5245@rymes.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9049205958511794898==" List-Id: --===============9049205958511794898== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed, 2017-02-15 at 10:56 -0500, Tom Rymes wrote: > Michael, et. al., >=20 > 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. >=20 > This has benefits for resources and entropy, I suppose, but those are not o= f 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. HOWEV= ER: > the auto=3Droute 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 bigge= st benefit of all of this that not all connections are active all the time. Do you set your connections to auto=3Droute in all branches or just in HQ? > Our experience is that using the auto=3Droute setting GREATLY improves the > robustness of the tunnels when it come to re-establishing them after someth= ing > 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 st= ays > down until manually brought back up when auto=3Dstart. If auto=3Droute, tho= ugh, > that tunnel will be re-established more reliably in such a scenario. Changi= ng > that setting has substantially improved our tunnel reliability. >=20 > Thanks for your attention to this, I know all of your time is in short supp= ly! > I will do my utmost to try and test the changes. -Michael >=20 > Tom >=20 > >=20 > > On Feb 15, 2017, at 9:54 AM, Michael Tremer > > wrote: > >=20 > > Hello guys, > >=20 > > sorry for my absence in the last few days and weeks. This list has been m= ore > > 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. > >=20 > > This morning I worked on a small feature which is probably quite > > interesting: > > On-demand IPsec VPN tunnels. > >=20 > > 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 strongSw= an > > to > > bring up the tunnel and send the packet. > >=20 > > When the VPN tunnel has not transferred any packets for 15 minutes, it wi= ll > > terminate it and restart it when it is needed again. > >=20 > > 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 ma= ke > > 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. > >=20 > > This is probably not much, but we have seen machines with only few entropy > > and > > we have seen IPsec becoming unstable then. > >=20 > > The web user interface shows the status if a tunnel is idle or connected. > >=20 > > Patches are in next: > >=20 > > =C2=A0http://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommitdiff;h=3Ddcb406= cc675c42f9add4 > > a41c8a1e07eea7c3ab08 > > =C2=A0http://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommitdiff;h=3D1ee166= 6ee45268db405a > > 66b8ec05501c718e7702 > > =C2=A0http://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommitdiff;h=3D8057ab= 15b9efeecf8eca > > 7ad4ebba170f141bd3de > >=20 > > 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. > >=20 > > I am not sure if this will cause some problems with some applications that > > rely > > on fast establishing of connections. > >=20 > > Looking forward to hearing your feedback! > >=20 > > Best, > > -Michael --===============9049205958511794898== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjIKCmlRSWJCQUFC Q2dBR0JRSllwSDA1QUFvSkVJQjU4UDl2a0FrSDhHVVArUFlidEttQnFRTW0xRUdEd2k2bFh0OUEK R2xZNVIydTVhTFliY0tJY2w0ZkFXbndYdjQvN2IxaDVHckRDMjBJcjVTWUNvMHVUUnJId3gzT0Z4 NGxHK0hVdwpNaUxHQTJIY0VDSCtxVUVHQXZWNXdIaHh5cnk2L1hHdGxvS3FFb1dZeTVwSkxHM0JG RFQ3WEZwcXZrSkZQWlBQCkp1aU9nRVRTM0dqdWVQUTAyQnZBdm5jRnNWTjh5WElmcjVteFNRYkJE TnZLM0FwSE9WMmV2Z0ZoR2Exc1BRTGUKUGtLbUZRclVJa0k5VVVlMklZL0c4UVRIQ1ZrVmhGeFFi MXAyU0crN1E2dzRFdVNMS2Urc3pVUk5mcmlNNUF3dQo1S2dVaVBWUngrbXhFOXQvNlEzbU4rVkRO R3Q2WVhWSHhaYXVxUkp2L3hNREJZM3h3MGRyUlFCVUd4RkxHYjlOCldmRFNGMWI2aXA3WHZ6TmJu YmlYUkdoczBIdzBPTUJGYi9WQ1BFRnBGM0V1dUZXTkxIc2xLM216ZGFFMk1IZ20KeThKMStBbkg5 SnNpZGJEVFE3YUMxYWFmY3JIVkg3NmZWZmVUUW1vZmppbmVxb3hCVG1PWW1tbDNxRWtlZjlWZgp6 dUFKUWJvbHBjOTUwWXRLUkx4aVpMSzgzbU9DZG4ydDdpeVorQk8wcFlkWi9jeFpHN0FrZUVpZzFP TEVEb1dtCjFhZE5kaTBsaTUxcTFvK2NoNW5ob0Jac3NwYnhUWWpvSEZlRGlHVVN0aVNaZXlXNHZ1 dVROMHpjazJKZUxmb0gKVklUcmI3Z3Z1R2tLNkRyWWtGVDFIK1JoZnFmSlBmRHc2VWVHRnhUSGcr NkJNa2lPUzNFdG9jU1VVM1hPUURueQpBQThpMlRBUmVaUDZhRTVYWDgwPQo9eXNSSgotLS0tLUVO RCBQR1AgU0lHTkFUVVJFLS0tLS0K --===============9049205958511794898==--