From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: [PATCH 1/2] ipsec: Add script to ensure VPNs are always on Date: Wed, 05 Feb 2020 17:22:36 +0000 Message-ID: <36D59040-B7E1-4713-816F-40A2EF440D7A@ipfire.org> In-Reply-To: <3d9d5a30-8bec-cbe2-0dc5-2792ad057220@rymes.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5846999588546498588==" List-Id: --===============5846999588546498588== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, > On 5 Feb 2020, at 17:19, Tom Rymes wrote: >=20 > On 02/05/2020 11:53 AM, Michael Tremer wrote: >> Hi, >>> On 5 Feb 2020, at 15:23, Tom Rymes wrote: >>>=20 >>> I probably misunderstood something here, but if we're setting all tunnels= to auto=3Droute, what's the difference between On-Demand and Always-On? >> Thank you for looking at this. Good question. >> For strongswan there will be no difference any more, but the script that c= hecks the tunnels every 5 minutes will only try to bring up the =E2=80=9Calwa= ys on=E2=80=9D tunnels. >=20 > OK, I see what you mean. May I suggest that we eliminate the distinction be= tween "Always-On" and "On Demand" and just retain the time limit for inactivi= ty? Tunnels set to have a limited time before being shut down to inactivity s= houldn't be brought back up by the script and those that do not should be. That would still change one more thing. We would then decide to always keep a= ll tunnels up. I am not sure if that has any disadvantages for anyone really.= But we would definitely have to drop the timeout, too, because otherwise the= tunnel will be brought down and the script will bring it back up again short= ly after. This has crossed my mind when I wrote the script today. >=20 >>> Also, this should be a nice improvement for reliability, as lots of folks= don't know that choosing "Always-On" means "auto=3Dstart", which is far less= reliable. >> I think it is best to not offer these options any more. I suppose this onl= y matters for users where one peer is behind NAT. Then you want to make sure = that the tunnel is always up (but wouldn=E2=80=99t you normally always care a= bout this?) or you would want the other side not to initiate a connection. >=20 > Maybe you're saying the same thing I just said up above? Yes :) >=20 > tom --===============5846999588546498588==--