WireGuard Two Half Routes vs 0.0.0.0/0 in wg-quick

Two /1 prefixes cover exactly the same IPv4 addresses as a single /0, and that equality holds only inside the peer's allowed-prefix list. It stops holding the moment the setup tool decides how to route, because Linux wg-quick handles a default prefix as a special case rather than as arithmetic. The special branch installs a dedicated table, two policy rules, a socket mark and reverse-path settings that a pair of half routes never receives. So when a proxy or a browser stops working after the edit, the prefixes are the least interesting part of the change.

The Prefix List Is Not the Whole Configuration

AllowedIPs does two jobs at once, and only one of them is about coverage. For WireGuard itself the list is cryptokey routing: it decides which destinations are encrypted toward a peer and which source addresses that peer may use. For wg-quick the same list doubles as a route specification, and the route it produces depends on which branch the list happens to match. Identical coverage across two different list shapes therefore says nothing about identical host state.

The default configuration takes that decision out of your hands, since Table defaults to automatic and the tool chooses where the routes land. A different network manager, a distribution wrapper or a custom Table value changes the outcome again, which is why advice written for one host can look wrong on the next.

What the Default Branch Adds Beyond a Route

A /0 entry sends wg-quick into its default-route path: a separate routing table receives the default, one policy rule sends unmarked traffic there, a second rule keeps more specific main-table routes authoritative, and the interface gets a firewall mark applied to its own socket. That mark is the loop guard. The encrypted datagrams carrying tunnel traffic leave with the mark set, so the rule that steers everything else into the tunnel does not swallow the tunnel's own transport packets.

A pair of /1 entries takes the ordinary route path instead. Two routes land in the configured table, and none of the surrounding machinery appears, not because it is unnecessary but because that code path was never entered.

Where the Two Arrangements Diverge

The divergence shows up first as recursion. With the half routes in the main table, the peer's own transport address falls inside a tunnel prefix, so the packet that should carry the tunnel matches a route pointing into the tunnel. Something has to exempt it: a host route for the current endpoint, a mark applied by hand, or an interface-specific rule. A host route works until the endpoint address changes, which happens with DNS-based endpoints, roaming clients and multi-peer configurations.

Second, anything that reasons about marks changes behaviour. A transparent proxy that redirects connections locally creates new sockets whose marks and sources differ from the original client flow, and the policy rules generated by the default branch were part of what sorted those flows out. Reading the proxy's own outbound connection is a different exercise from testing whether the original destination is reachable.

Read the Rules and Marks Before Editing

Capture the current state while the tunnel is healthy, then again after the change, and compare the two dumps rather than reasoning from the configuration file. Include the policy rules, every table, the interface's mark and the recorded endpoints.

ip rule show
ip -4 route show table all | grep -E 'default|wg1'
wg show wg1 fwmark
wg show wg1 endpoints

If the first line of output has lost the unmarked-traffic rule and the dedicated table is empty, the default branch is not running and no amount of prefix arithmetic will restore its effects. A mark of zero on an interface that previously carried one is the same signal, visible in a single value.

Rehearse Tunnel Loss Before Shipping

If the half-route layout is the deliberate choice, it has to supply the missing pieces explicitly: an endpoint path that survives address changes, the intended behaviour when the tunnel drops, and the equivalent treatment for IPv6. Write those down as requirements rather than discovering them during an outage. Then rehearse the failure, because a full tunnel that silently falls back to the physical uplink is worse than one that stops working.

sudo ip -4 route add 198.51.100.20/32 via 192.0.2.1 dev eth0
ip -4 route get 198.51.100.20
sudo wg-quick down wg1

The route lookup should resolve the endpoint out of the physical interface without traversing the tunnel, and bringing the interface down should leave the host in the state the design promised. A proxy that works after the replacement proves that the generated host state mattered; it does not prove that loop prevention and down-state behaviour survived the edit.