Skip to content

fix: revoking a WireGuard client drops PostUp/PostDown from wg0.conf #44

Description

@catinspace-au

Revoking a WireGuard client rewrites wg0.conf without the operator's PostUp and PostDown hooks, so the next container restart brings the interface up with the operator's firewall rules missing.

revoke_wireguard_client (scripts/revoke-client.py) calls wireguard.generate_server_config() with private_key, network, listen_port, mtu, peers_dir and alloc_file, and nothing else. post_up and post_down default to "", so both lines are dropped from the regenerated file.

generate_wireguard_configs in generate-client.py passes both, and the comment above it spells out why:

wg_conf and the PostUp/PostDown hooks are needed because issuing a client rewrites the server's own config: writing it anywhere but wg_conf leaves the running server unaware of the peer, and dropping the hooks would silently discard the operator's own firewall rules.

The revoke path does exactly the thing that comment warns against.

It does not bite immediately, which is what makes it nasty. wg syncconf only touches the peer list, so the live interface keeps working with the rules already installed. The loss surfaces on the next wg-quick up -- a container restart, a host reboot, a watchtower image bump -- and it surfaces as clients connecting fine and then reaching nothing, with no error anywhere.

Latent on devex, where CULVERT_WG_POST_UP is unset. Live for any deployment that uses the hooks for its own NAT or filtering.

Done when revoking a client leaves the PostUp and PostDown lines in wg0.conf unchanged.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions