From: Michael Tremer <michael.tremer@ipfire.org>
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 [thread overview]
Message-ID: <36D59040-B7E1-4713-816F-40A2EF440D7A@ipfire.org> (raw)
In-Reply-To: <3d9d5a30-8bec-cbe2-0dc5-2792ad057220@rymes.com>
[-- Attachment #1: Type: text/plain, Size: 1825 bytes --]
Hi,
> On 5 Feb 2020, at 17:19, Tom Rymes <trymes(a)rymes.com> wrote:
>
> On 02/05/2020 11:53 AM, Michael Tremer wrote:
>> Hi,
>>> On 5 Feb 2020, at 15:23, Tom Rymes <trymes(a)rymes.com> wrote:
>>>
>>> I probably misunderstood something here, but if we're setting all tunnels to auto=route, 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 checks the tunnels every 5 minutes will only try to bring up the “always on” tunnels.
>
> OK, I see what you mean. May I suggest that we eliminate the distinction between "Always-On" and "On Demand" and just retain the time limit for inactivity? Tunnels set to have a limited time before being shut down to inactivity shouldn'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 all 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 shortly after.
This has crossed my mind when I wrote the script today.
>
>>> Also, this should be a nice improvement for reliability, as lots of folks don't know that choosing "Always-On" means "auto=start", which is far less reliable.
>> I think it is best to not offer these options any more. I suppose this only matters for users where one peer is behind NAT. Then you want to make sure that the tunnel is always up (but wouldn’t you normally always care about this?) or you would want the other side not to initiate a connection.
>
> Maybe you're saying the same thing I just said up above?
Yes :)
>
> tom
next prev parent reply other threads:[~2020-02-05 17:22 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-05 11:24 Michael Tremer
2020-02-05 11:24 ` [PATCH 2/2] ipsec: Silence charon Michael Tremer
2020-02-05 15:25 ` Tom Rymes
2020-02-05 16:55 ` Michael Tremer
2020-02-05 17:16 ` Tom Rymes
2020-02-05 15:23 ` [PATCH 1/2] ipsec: Add script to ensure VPNs are always on Tom Rymes
2020-02-05 16:53 ` Michael Tremer
2020-02-05 17:19 ` Tom Rymes
2020-02-05 17:22 ` Michael Tremer [this message]
2020-02-05 17:36 ` Tom Rymes
2020-02-06 15:03 ` Michael Tremer
2020-02-06 20:06 ` Tom Rymes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=36D59040-B7E1-4713-816F-40A2EF440D7A@ipfire.org \
--to=michael.tremer@ipfire.org \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox