PiVPN with Wireguard add keep alive

[LOGIN-TB]

Is your feature request related to a problem? Please describe:

Installing a wireguard vpn server (software package 117) creates a wg0.conf for server and a vpn.conf for each client. Behind router or firewall with nat. the tunnel will be suspended if there is no traffic. you cannot reach the client from the server anymore unless the client sends a packet to the server: Quote (WireGuard website) "By default, WireGuard tries to be as silent as possible when not being used; it is not a chatty protocol. For the most part, it only transmits data when a peer wishes to send packets. When it's not being asked to send packets, it stops sending packets until it is asked again. In the majority of configurations, this works well. However, when a peer is behind NAT or a firewall, it might wish to be able to receive incoming packets even when it is not sending any packets. Because NAT and stateful firewalls keep track of "connections", if a peer behind NAT or a firewall wishes to receive incoming packets, he must keep the NAT/firewall mapping valid, by periodically sending keepalive packets. This is called persistent keepalives."

Describe the solution you'd like:

Add this line under peer in the wg0.conf on the server and in the client vpn.conf as well: PersistentKeepalive = 25

For further information check WG website under NAT and Firewall Traversal Persistence:

https://www.wireguard.com/quickstart/

[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 https://github.com/pivpn/pivpn/pull/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.