WireGuard Default Route Loop: Find the Endpoint Path

The interface comes up, the peer configuration looks correct, and no handshake ever completes. Adding a default route through the tunnel is the step that often causes it: the same route table now decides where the tunnel's own encrypted packets should go, and the answer it produces is back into the tunnel. Nothing can carry the outer packet that would carry the inner one, so the connection stalls before it starts. The repair is small, but it has an order, and the verification matters more than the edit.

Confirm the Loop Before You Change a Route

Read the peer's current endpoint address and then ask the routing stack where a packet to that address would go. If the answer names the tunnel interface, the loop is confirmed and no further diagnosis is needed. Store both outputs in the change record before touching anything, because the comparison after the fix is the same two commands. A loop is not subtle once it is seen; the difficulty is that the interface looks healthy while it happens.

sudo wg show wg1 endpoints
ip route get 198.51.100.20
ip rule show

Include the policy rules in that capture. A default route that looks correct in the main table can still lose to a rule that selects a different table for marked or unmarked traffic, and the loop will reappear with a route table that appears fine.

Read the Endpoint Path, Not the Tunnel Path

The endpoint path is the route the encrypted datagrams take to the peer's public address, and it has to stay outside the tunnel for as long as the tunnel exists. The tunnel path is everything the peer is allowed to carry. Those two paths share a route table, which is exactly why a single catch-all entry can collapse them into each other. Cutting the tunnel traffic and the tunnel's own transport apart is the whole design problem, and every supported tool solves it somewhere slightly different.

Check both address families separately if the interface carries both. A working IPv4 exclusion tells you nothing about whether the IPv6 endpoint is still reachable, and a mixed configuration can appear to work until the peer's IPv6 address is selected.

Restore the Endpoint Path With One Coherent Change

Two supported approaches exist, and mixing them is how a working setup becomes unpredictable. The first is to let the tool that owns the interface handle the full tunnel: wg-quick has dedicated handling for a default peer range that installs a separate table, policy rules and a socket mark, which keeps the outer packets out of the tunnel. Leave that machinery intact rather than reproducing half of it by hand. A setup that mixes a manually added default with a manager that already installs marks and rules tends to fail after reconnect, when the manager rewrites state that the manual step assumed.

The second is a manual design in which the endpoint gets an explicit host route through the physical gateway. Add that route before the default, replace rather than append so a stale entry cannot win, and confirm the lookup afterwards.

sudo ip route replace 198.51.100.20/32 via 192.0.2.1 dev eth0
ip route get 198.51.100.20
sudo ip route add default dev wg1

Verify, Then Keep a Way Back

A handshake timestamp that advances is the first proof, and it is stronger than an interface that merely exists. Follow it with an application test through the tunnel, then bring the interface down on purpose and confirm the host returns to a usable state rather than holding a default route pointing at nothing. That last step is the one people skip, and it is the one that decides whether a reboot will strand the machine.

sudo wg show wg1 latest-handshakes
sudo wg-quick down wg1
ip route show default
ip route get 198.51.100.20

Before any of this, save the current routing state and make sure there is a way in that does not depend on the tunnel: a console, an out-of-band management address or a colleague on site. A remote machine that loses its default route is not recoverable over the connection it just lost, and the safest runbook step is the one taken before the first command.