PiVPN with Wireguard add keep alive

[LOGIN-TB]

PiVPN with Wireguard add keep alive

[Joulinar]

Hi Holger, I think that would be more of a task for the PiVPN developer to add the PersistentKeepalive value to their script. We don't do anything with the PiVPN toolset except install it.

[LOGIN-TB]

Hi Michael,

ok, got it. Thanks for clarifying

[Joulinar]

usually it should be there already pivpn/pivpn#1321

Can you check pivpn -d for current values

[LOGIN-TB]

these values are missing this entry

[MichaIng]

In our default WireGuard client configuration we have this:

# Uncomment the following, if you're behind a NAT and want the connection to be kept alive.
#PersistentKeepalive = 25

So it is commented. Do you think it makes sense to have this enabled by default?

Probably it would be also possible to add it to each [peer] block of the server config, so the service keeps the connection to the clients active, regardless what the clients do. But this somehow sounds wrong 😄.

[LOGIN-TB]

Makes sense to set it as default, its recommended for NAT scenarios.

[MichaIng]

In case of PiVPN, it was added as optional setting for unattended installation using the --unattended command line parameter (which we support by creating this config as /boot/unattended_pivpn.conf). The example config contains this setting, but since this is not meant to be used as is, but more for documentation reasons, one must add it manually. Not sure if the latest PiVPN UI probably has a dialog about it as well?

For our own WireGuard implementation, and in general, I wonder how common the case is that you want to access a client from the server. But it also allows to access one (remote) client from another client. It is also possible to set this on the server, but somehow this feels wrong: Each client should decide whether it wants its connection to stay active, and whether it is even needed (client behind NAT or not), and not the server enforcing it.

I was reading a bit, and I think in general the default (no keep alive) is a good default, and covers the most common use cases, where the client wants remote access to some LAN, to the server only (e.g. for Pi-hole), bypass an untrusted public AP, plain-HTTP connection or country limitations for streaming and such. If the client is even meant to be accessed from any other peer, and shall in case have its traffic and energy usage (mobile phone) increased with a permanent connection, is better to be intentionally decided by the admin respectively the user of each client only.

What I anyway would love to have is some more dialogs to create and configure one or more client configurations. Currently the config contains a bunch of comments with example configs and values for different use cases instead. A dialog and also dietpi.txt settings to automate everything.