Two WireGuard peers share a range: which one gets the packet

Two peers list ranges that touch, and traffic reaches the wrong one. Nothing is corrupted: WireGuard picks a peer by matching the destination against the configured ranges, and the most specific match wins. Before you widen anything, decide which peer is supposed to own which prefix.

The longest prefix wins inside WireGuard

Each peer entry carries a set of destination prefixes. When a packet is routed into the interface, the implementation looks for the entry with the most specific matching prefix, the same rule a routing table applies. A /24 therefore beats a /16 that contains it, and the narrower peer receives the traffic.

Road-warrior setups use this deliberately. One peer owns a broad range for a site, and individual hosts are carved out with /32 entries that belong to other peers. The pattern works because the carve-outs are more specific, not because of ordering.

Write the ownership down as a table of prefix and peer. If two entries describe the same prefix, the configuration no longer expresses an intent, it expresses a race.

The operating system picks the interface first

WireGuard only chooses among the peers on one interface. Which interface receives the packet is decided earlier, by the host routing table, and a second default route or a stale route can send the traffic somewhere the peer list never sees. That is why a peer-level diagnosis can be correct and still not explain the failure. Check the route for the destination before reading the peer configuration, because a route pointing at the physical interface bypasses the whole question.

The tool usually installs those routes from the peer ranges, which means a change to one peer's list can silently re-point traffic that used to belong to another. A peer edit is therefore a routing change in disguise. Review both at once, or you will fix one and break the other.

Incoming packets are checked by source

The range list does double duty. For outbound traffic it selects a peer by destination, and for inbound traffic it authorizes a source address. A packet arriving from an address outside that peer's ranges is dropped before any firewall sees it.

That asymmetry is easy to miss when you are reading one side of the configuration. A peer that can reach a subnet is not thereby permitted to send from that subnet, and the two directions are enforced by different checks.

Narrow source ownership turns this into an advantage. Give each peer a /32 for its own address and the firewall downstream has a trustworthy source to match, rather than a group-wide range that any member could claim.

Duplicate ranges are not failover

Assigning the same prefix to two peers does not create a load balancer or a standby path. There is no health check and no session affinity: the entry that wins is decided by the implementation's internal ordering, which is not a contract you should design around. If you need alternate exits, express them where selection is defined. A routing policy, a metric, or a pair of distinct prefixes with a documented owner each produce behaviour you can predict and test.

Broadening a range to fix an unrelated failure is the other common mistake. It moves traffic away from the peer that was working, and the new symptom arrives before the old one is understood.

Verify the selection before editing

Three commands answer the three questions in order. The first lists the ranges each peer claims. The second shows which interface the host would use for a destination. The third shows live peer state after traffic has flowed.

wg show wg0 allowed-ips
ip route get 10.66.8.20
wg show wg0
ip rule show

Run them before and after a change and compare. If the route output changed but the traffic still arrives at the wrong peer, the prefix lists overlap in a way you have not written down yet. If the route output did not change, the peer configuration was never the thing being consulted.

Record the destination, the chosen interface and the chosen peer in the ticket. That triple is what makes an overlap reviewable later, and it is far more useful than a screenshot of the configuration.