NetworkManager vs wg-quick: Who Owns Your WireGuard Routes

You change AllowedIPs in the WireGuard file, restart the tunnel, and the routing table looks exactly as it did before. The usual reaction is to delete the offending route and move on, which works until the next reconnect puts it back. The file you edited is not necessarily the object that produced the state you are looking at. Two managers can run the same protocol on one machine, and only one of them owns the interface at a time.

Myth: there is one WireGuard config on the machine

wg-quick reads a file under /etc/wireguard/ and builds the interface when you bring it up. NetworkManager stores a connection profile in its own keyfile format and renders it at activation, and importing a wg-quick file copies the values into that profile rather than linking to it. Editing the original afterwards changes nothing, because the profile no longer reads it. The same list of peers and keys can therefore exist twice, with the second copy in force.

A tell worth remembering: edits that survive a reboot but not a re-import came from one store, and edits that vanish at reboot came from the other.

One practical example makes the split obvious. Compare nmcli connection show with systemctl status wg-quick@wg0, then check which interface the routes actually hang off. If the service is dead and the interface is up, the profile is doing the work, whatever the file says.

Myth: the routing rules are part of WireGuard

The kernel WireGuard device knows peers and keys, and it knows nothing about policy routing. Whatever ip rule entries and extra tables you see were installed by the tool that brought the interface up. wg-quick can add a fwmark and a dedicated table plus rules pointing at it, while NetworkManager installs routes through its own ipv4 settings and leaves DNS to whichever resolver backend the system uses. Same tunnel, different side effects.

Read ip rule and ip route show table all before changing anything, and note which table each route lives in. A table number you did not configure is a strong hint about the tool that created it.

Myth: deleting the route is a fix

A route deleted at runtime is a route the owner will reinstall on the next activation, and the activation may happen without you: a laptop resume, a link flap, a service restart or a NetworkManager autoconnect. That is why the same route returns and why the workaround feels unreliable rather than wrong. Identify the manager first, then change the input that manager actually reads.

Reconnecting and restarting the relevant service is the test that separates a real fix from a tidy-looking one.

Pick one owner and remove the other

Choose the manager your deployment supports, then disable the competing activation through its documented control rather than hoping it stays idle. A masked wg-quick service or a deleted NetworkManager profile is explicit; leaving both enabled and racing them is not. Preserve working access before you disable anything, because the interface carrying your remote session may be the one you are about to remove.

After the change, verify included and excluded traffic, then DNS, then reboot once. If the state survives a reboot with a single manager, you have an owner instead of a coincidence.

The general rule is worth keeping beyond WireGuard: when a setting keeps coming back, stop deleting the result and find the process that keeps producing it.