Hi,
On 5 Feb 2020, at 17:19, Tom Rymes trymes@rymes.com wrote:
On 02/05/2020 11:53 AM, Michael Tremer wrote:
Hi,
On 5 Feb 2020, at 15:23, Tom Rymes trymes@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