Recursive Routing: When the Tunnel Captures Its Own Packets

The tunnel comes up, the log shows a completed handshake, and a second later the same session dies and reconnects on a loop. That pattern has a specific cause: the route to the server now points into the tunnel, so the packets carrying the tunnel are sent through the tunnel. Nothing about authentication changed, which is why re-entering credentials makes no difference. Compare the outer path before and after the route change and the recursion becomes visible.

Check the Outer Path First

There are two packets in play, not one. The inner packet belongs to the application and should be encrypted, while the outer packet is addressed to the server and must reach it over a path that does not depend on the tunnel.

ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints

Ask the kernel for the route to the server's address after the tunnel is up, and again after the default route changed. A next hop that lands on the tunnel device is the recursion, and it is visible without any packet capture. Interface binding, marks or a network namespace can make a plain lookup incomplete, so use the context the client itself uses. When the answer looks correct but the session still loops, read the routing policy rules rather than only the main table.

Why the Session Survives for a Moment

The handshake completes before the new route is installed, so the first seconds look healthy. Once the client adds the default route, the next outer packet follows it into the interface that needs that outer packet to travel. The server sees nothing, the client retransmits, and the retry either times out or kills the session and starts over.

That ordering explains why a tunnel can work on a laptop and fail on a router, and why the failure often begins when traffic starts rather than at connect time. It also explains the loop: every restart re-establishes the session before the route makes it impossible.

Find Who Owns the Endpoint Exception

Supported clients arrange their own exception: a host route to the server through the original gateway, or a mark that keeps the outer socket out of the tunnel. The question is whether something else removed or overrode it.

For route-based IPsec, inspect the policy selectors that decide which packets enter the tunnel, and confirm the peer address is excluded from them. For WireGuard, the interface's firewall mark and its policy rules keep the transport packets outside the tunnel, so a manually added default route can break that arrangement. A second VPN profile or a management script that rewrites the default route is a common culprit. Broad bypass rules added one at a time are the usual result, and they turn a routing bug into a table nobody can maintain.

Recheck After a Network Change

A host route through a Wi-Fi gateway is correct until the machine moves to a different network. The same symptom then returns with no configuration change at all.

Record the endpoint address, the route before and after connecting, and the interface each one used. Those three facts usually separate a client bug from an override, and they survive the person who collected them.

Reconnect on the new network and repeat the read. If the exception is missing again, the fix belongs in the profile that owns it, not in a one-off command typed during an outage.