Thanks for the recent support of wireguard via flannel. Given that k3s targets the Edge, IoT and ARM devices, there is one issue with the current implementation: Wireguard by default does not send keepalive packets to keep tunnels alive.
This is great if both endpoints can connect directly, they will just resume the wg connection on demand.
However if there is a NAT involved, the connection just dies and can't be resurrected from the "outside" part of the NAT.
TL;DR
There should be a way to configure keep-alive pings as described in https://www.wireguard.com/quickstart/#nat-and-firewall-traversal-persistence
While I would love to be able to configure the limit, the wg documentation says
"A sensible interval that works with a wide variety of firewalls is 25 seconds. Setting it to 0 turns the feature off, which is the default, since most users will not need this, and it makes WireGuard slightly more chatty."
So a persistent-keepalive setting with 25 seconds could be a great hard coded default for all deployments IMHO.
a great hard coded default for all deployments
The great hardcoded default in Wireguard is "0" and the reasons for that are on the Wireguard page you linked. I don't think that making everyone's connections more spammy just for a few NAT users is a great default. Making it configurable is definitely useful, setting it to something different than 0 isn't in my opinion.
I think that a KeepAlive makes sense, the helpfulness of keeping the connection alive probably outweighs the amount of data used for that request when using wireguard. I am not sure where this would be configured tho, please feel free to open a PR.
I don't want connections to stay alive if they don't have to, this is the opposite of helpful (unless you are behind a NAS of course).
Is there a reason besides that it is "slightly more chatty"? It seems fairly helpful to set a Keepalive, and encryption is maybe most needed when using different networks through a nat.
a great hard coded default for all deployments
The great hardcoded default in Wireguard is "0" and the reasons for that are on the Wireguard page you linked. I don't think that making everyone's connections more spammy just for a few NAT users is a great default. Making it configurable is definitely useful, setting it to something different than 0 isn't in my opinion.
As you might now, WireGuard was developed from a malware/white hat tooling perspective: It should be as undetectable as possible. However in the meantime vendors already identified typical packets to detect a wireguard connection. Almost all other VPN/overlay networks - to my knowledge - send keep alive packages.
In a distributed environment with k3s the current default just breaks things.
Is there a reason besides that it is "slightly more chatty"? It seems fairly helpful to set a Keepalive, and encryption is maybe most needed when using different networks through a nat.
WireGuard was originally designed as a white hat tool to exfiltrate data from networks without being able to be detected the VPN easily when not transmitting data. Of course for a long running connection in "hostile" environments it makes sense to stay as silent and undetectable as possible.
For a k3s scenario thins does not make any sense as they are pretty exposed/detectable by default.
As far as I understand the code, the commands to set up WireGuard (the place one would also configure the keepalive) are hard coded in flannel. 馃檨
We should have enough control over the setup, I think it should either be in
https://github.com/rancher/k3s/blob/ba240d06119a9de9f546c37f7777d96ccc2e37be/pkg/agent/flannel/setup.go#L58
or
https://github.com/rancher/k3s/blob/959acf9c92935a7a526f4df3ff903c2858510b0e/scripts/wg-add.sh
Fixed in v1.17.0-rc4-k3s.1
Most helpful comment
The great hardcoded default in Wireguard is "0" and the reasons for that are on the Wireguard page you linked. I don't think that making everyone's connections more spammy just for a few NAT users is a great default. Making it configurable is definitely useful, setting it to something different than 0 isn't in my opinion.