WireGuard AllowedIPs: The Route NetworkManager Never Added

The handshake counter updates, the interface holds its address, and a ping to the far side goes nowhere. That combination confuses people because a working handshake feels like proof that the tunnel is ready. It is not: a tunnel can be fully negotiated and still have no route pointing traffic into it, and those are two separate jobs performed by two separate pieces of state. The fix depends entirely on which of the two is missing, so the first step is to find out.

wg-quick performs both without being asked. NetworkManager's built-in WireGuard support also installs peer routes by default, which narrows the suspects to a disabled option, a different routing table, or a configuration imported through something else.

Confirm the tunnel before chasing the route

wg show prints the interface, the peer, the endpoint and the age of the latest handshake, and ip addr show confirms the address is present. A recent handshake means the keys, the endpoint and the UDP path are working. Whatever is broken sits downstream of them: routing, filtering or name resolution.

Then ask the kernel what it would do with a real destination instead of a hypothetical one: ip route get 10.42.7.9. The answer names the outgoing interface and the source address the packet would carry. When it names the physical adapter, the packet never enters the tunnel no matter how healthy the handshake looks.

AllowedIPs is a filter and a route list

The prefixes in AllowedIPs do two jobs. They select which peer carries an outgoing destination, and they validate the source address of incoming packets, which is the cryptokey routing boundary. In wg-quick they also drive automatic route installation, and that extra behaviour is why the same configuration works from a terminal and not from a desktop client.

In the case behind this article, the profile was imported through a third-party plugin rather than through the built-in support, and the interface came up without the prefix route. Listing the table shows it immediately: ip route show contains only the connected route for the interface address, and nothing for the remote range.

Ask whether peer routes are enabled at all

Read the setting before you modify anything: nmcli -f wireguard.peer-routes,ipv4.route-table connection show work-wg. When peer-routes reads no, the supported repair is nmcli connection modify work-wg wireguard.peer-routes yes, followed by a reconnect. Adding a static route instead works until the next activation and then quietly disappears. That disappearance is the tell: a route that comes back as a mystery every morning is not being installed by the profile.

If the option is already enabled, check whether the prefix lives in another table with ip route show table all | grep 10. A route in a non-main table is not missing, it is simply invisible to a lookup that only consults the main table. Fix the policy routing rather than stacking a duplicate entry on top.

Add the prefix to the connection, not to the running system

In the connection editor, the WireGuard page holds the peer and its AllowedIPs, and the IPv4 page holds additional routes. A route added there survives reconnects because it belongs to the profile. On the command line the equivalent is appending a route to the connection with the empty-gateway form, then cycling the connection down and up so the change is applied.

Choose the narrowest prefix that covers the hosts you need. Copying the provider's example /8 can swallow local ranges that happen to sit inside it, and the resulting failures look like a broken tunnel rather than an over-broad route.

Split tunnelling is decided by the prefix list

There is no split-tunnel switch; the prefix list is the decision. A peer with one range for the office LAN and one for a lab network sends exactly those destinations through the tunnel and leaves everything else alone. A single host needs a /32, and overlapping ranges at two sites need host prefixes until somebody renumbers a subnet.

Choosing to send nothing through the tunnel takes the same decision to its limit: a minimal list leaves the link up while ordinary traffic keeps to its usual path. Write the intent down, because the next reader will otherwise treat the short list as an oversight and helpfully extend it.

One owner for the route table

wg-quick and NetworkManager both believe they own the interface's routes. Import a config written for wg-quick and then also start the wg-quick service, and you get duplicated or conflicting entries whose behaviour depends on which one ran last. Pick a single owner and remove the other: if NetworkManager manages the connection, disable the wg-quick unit for that interface, and never add a second profile for the same device.

When the split has to follow a physical adapter instead of a destination, you have moved into policy routing, and policy routing needs a single author as well. Verify by repeating ip route get, then reaching a host inside the remote prefix with something that prints the source address it chose. Check IPv6 and DNS separately if the profile carries either.