[FEAT] Always-OnKill Switch in Client-mode

[mtalexan]

Is this a new feature request?

• I have searched the existing issues

Wanted change

Support or document setting default iptables rules to block all traffic ("Always On Kill Switch") before any wireguard interfaces are loaded.

I would like to be able to block all non-local network connections until a successful wireguard connection is brought up, and return to that state if wireguard is brought down. Including if I have more than 1 wireguard interfaces configured, or if the wireguard module needs to be (re)built.

Reason for change

For users using this in Client mode with network_mode: container or network_mode: service, it's a desirable feature to support an "Always On Kill Switch" like many VPNs have.

#246 discusses this and PreUp is suggested, but that can only solve the problem if:

1. A valid wireguard config is actually loaded containing it.
2. That config is the first loaded (so it doesn't block the other wireguard interfaces while it loads, or override their PostUps).
3. Wireguard service is always started immediately on container startup before anything else.

It might be ok to assume 1, but it's definitely sub-optimal organization of responsibilities.
The rules for satisfying 2 are at least documented, but it speaks to the suboptimal organization of responsibilities that you have to make sure the first (modular) wireguard config sets the default global (non-modular) initial state.
I don't see it in the repo, but it seems like the wireguard module might be built as a dkms module in certain cases, which would mean 3 isn't always true.

Proposed code change

An optional config file that sets/merges some default rules for the /etc/iptables/rules (?) and /etc/iptables/rules (?). Or at least document how to override them in the README.

[github-actions]

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

[aptalca]

This isn't something we will promote, address, or even mention. Doing so would bring a whole lot of liability to us and likely create a false sense of security for the user.

Leakage depends on how the configs are set up. For client mode, we don't even provide any configs, the user has to create their own.

There are many different ways to tackle the leakage issue and almost all of them depend on the user's specific config and requires personal customizations. There is no one standardized solution.

With that said, wireguard is stateless and as long as there is a valid config, the tunnel will come up, regardless of whether the other side is really connected or not. Plus, if the config is not valid and the tunnel fails, the container deletes the default route, killing network connectivity for the container.

The period where there is leakage by default is while the container is starting up. That part requires custom solutions, or you can make sure wireguard is up and running before other services are up and don't rely on unattended upgrades and such (you should never do that anyway for other reasons).

[mtalexan]

I think the "delete the default route" achieves what I was looking for anyway.