WireGuard Sends Data but Gets Nothing Back: Which Side?

Transmit counters that climb while the receive counter stays at zero describe a direction, not a diagnosis. The same reading appears when the peer never completed a handshake, when the destination chose the wrong peer, when the far side has no route back, and when a filter drops the reply on its way home. Each of those is repaired in a different place.

The comparison that shortens the work is between a request that never left the tunnel and a reply that never came back. One capture on the right interface decides between them.

Counters Describe Volume, Not Direction of the Fault

WireGuard's counters record what the interface handed to the peer and what it received from it. They do not say which destination, which peer or which half of an exchange failed. Background traffic makes the totals even less informative, since some bytes may be keepalives or unrelated flows. Read them as an indicator that the interface is active, then stop treating them as evidence.

The useful first fact is whether a handshake is current. Without one, nothing was encrypted for this peer and the receive counter has no reason to move.

Peer Selection or Reply Path: Two Explanations

The first explanation is that the packet never reached the intended peer, because the route pointed elsewhere or the peer's allowed prefixes did not cover the destination. The second is that the packet arrived and the reply could not return, which is a routing problem at the far end. The table separates them by what you would observe at each point.

Read the table from the top. A missing handshake sends you to keys, endpoints and the outer path, because nothing else exists to examine yet. A current handshake with the request visible on the server moves the problem into the return direction, where the destination's own route table decides. A request that never appears on the server is a selection problem, and the allowed prefixes on both peers are the first thing to compare.

Two of those four rows get fixed on the client and two on the server. Knowing which pair you are in is most of the work.

Where Replies Disappear

A reply leaves the destination, reaches the server's tunnel interface and gets encrypted for the peer whose allowed addresses match the client's inner address. If that match fails, the reply is discarded silently, which looks exactly like a network fault from the client side. If the reply is encrypted and the client's own filter rejects it, the symptom is identical again. Both cases need the capture rather than the counter.

The strongest version of this mistake is a server that forwards packets for the client but has no route back to the client's inner range. It accepts the request, sends the reply toward its default gateway, and the tunnel never sees it. A broad translation rule added to the server hides that fault instead of repairing the route.

Test One Destination End to End

Pick a single destination inside the peer's range, and test it while a handshake is demonstrably current. The commands below read the peer state, the chosen route and both sides of the exchange. Run the capture on the interface the encrypted packets actually use.

wg show wg0 latest-handshakes
wg show wg0 transfer
ip route get 10.60.9.5
sudo tcpdump -ni wg0 host 10.60.9.5

A capture showing the request on the tunnel interface with nothing coming back is a server-side answer, and the destination's route table is where to look next. Nothing appearing at all means the packet took another path, so the local route is the suspect. An exchange visible in both captures with no application progress moves the question to packet size or to a filter the interface statistics never show. Keep one destination and one client in the test, because a second variable turns evidence back into an impression.

If names fail while a permitted address works, the answer sits in DNS rather than in the tunnel. If only large transfers stall, examine packet size separately.