WireGuard Host Prefix: Why One Address Works and the Rest Do Not

The tunnel is up, the handshake happens every two minutes, and exactly one address on the other side answers. Pings to the peer's tunnel address work; nothing behind it does. Someone reads the interface configuration, sees a host prefix, and concludes that the mask is wrong. Widening it to a /24 fixes the ping for a while and then breaks something else. The prefix was never the fault, and the route that was missing is not the one the mask controls.

What the interface prefix actually creates

On Linux, assigning an address to an interface creates a connected route for that prefix. Assign a host prefix and the connected route covers one address. Assign a /24 and it covers 256, of which every one is now treated as reachable on that link.

ip -4 addr show dev wg0
ip -4 route show dev wg0
ip route get 10.80.7.1

A host prefix is a completely normal choice for a point-to-point tunnel, because there is exactly one peer at the other end. The third command is the one that answers the user's question: it says which interface the kernel would use for that destination, and it will show nothing useful if no route matches.

That is the whole explanation for the symptom. One address answers because a connected route exists for it, or because the peer's allowed list happens to include it. Everything else has no route and is dropped before WireGuard is involved. The tunnel is healthy throughout, which is why the handshake counter keeps looking reassuring.

AllowedIPs is two rules sharing one name

WireGuard's per-peer allowed list is doing two jobs at once, and the configuration syntax makes them look like one. Inbound, it authorises which source addresses a peer may present. Outbound, it selects which peer a packet is sent to, by finding the most specific match.

Neither job is routing. The kernel still has to decide that a packet belongs on the tunnel interface before WireGuard ever looks at it, and that decision comes from the routing table. A peer entry with a wide allowed list does not install a route by itself.

This is why a configuration can look complete and behave asymmetrically. The client sends to the far side because a route exists, and replies never arrive because the far side's allowed list does not authorise the client's source, or the far side has no route back. Both directions are separate decisions with separate failure modes. Writing down which one you are testing is half the diagnosis.

Where the route comes from

If you use wg-quick, the routes are generated for you from each peer's allowed list, unless you have set Table = off and taken ownership yourself. That is the behaviour the tool documents, and it is the reason a config with no explicit route directives still works.

sudo wg show wg0 allowed-ips
ip route show | grep wg0
sudo wg-quick strip wg0

Compare the allowed list with the routes actually present. A peer that permits a whole subnet but produced only a host route means the helper never ran, or you are managing the interface directly with wg and ip, in which case nothing is generating routes for you.

When you do manage it by hand, the route is one line and its shape is explicit: the destination through the interface, with no gateway because the link is point-to-point. Adding it is not a workaround for a bad prefix; it is the missing half of a design that chose to own routing manually.

Widening the prefix does not add the peer entry

The tempting fix is to change the address to a /24 so the connected route covers the server's LAN. It appears to work, and the reason it appears to work is that the connected route now matches, not that WireGuard learned anything new.

What you also did is claim the whole range as directly reachable on that link, including addresses that belong to other peers or to a LAN that is actually behind the server. Traffic to those addresses now enters the tunnel, and whether it comes out the other side depends on the server's own routing and allowed lists.

The crypto side is unaffected either way. WireGuard still needs an allowed list entry covering the destination to choose a peer, and the far side still needs an entry covering your source to accept it. A wider interface prefix cannot supply either.

Confirm both directions before changing anything

Work the two ends separately and write down what each one says. On the client, the route and the peer entry; on the server, the mirror image plus its own return path:

ip route get 192.168.70.20
sudo wg show wg0 allowed-ips
sudo wg show wg0 latest-handshakes
sudo tcpdump -ni wg0 -c 10

The capture is what settles disputes about direction. If outgoing packets appear on the tunnel interface and the server logs nothing, the far end is rejecting them, usually because your source is outside its allowed list. If nothing appears at all, the route is missing or pointed elsewhere.

Then fix the narrowest end. A server-side allowed list entry for your client address and a client-side entry for the destination subnet is the normal shape, and it leaves the interface prefix alone. Only widen the prefix if the address plan genuinely wants a shared subnet on that link, and do it as a plan change rather than as a debugging step.