WireGuard Handshake Succeeds but No Reply Comes Back

Recent handshakes are good news, and a much smaller claim than the sentence people want to write. The peers exchanged authenticated handshake messages. An application packet still has to reach its inner destination and come back.

That gap between a healthy control plane and a silent data plane is the whole subject here. Two readings of the same counters tell you which side of it you are on.

A Handshake Proves Keys, Not Delivery

The WireGuard handshake is a key agreement with authentication. It succeeds as soon as the peers can reach each other and hold valid keys. Routing, firewall policy and the destination itself are questions the handshake never asks.

So a tunnel can be perfectly established while every packet inside it is dropped. A misrouted inner packet and a reply that takes another path look the same from the client.

One Inner Address Is the Whole Test

Pick one destination and stay with it. The peer's own tunnel address is the easiest case, and a host behind the peer adds exactly one more hop. Alternating between them without noting the change produces results nobody can compare.

Then look at the route the client chooses. A more specific local route can send the packet somewhere else before WireGuard is consulted at all, which happens whenever the home LAN overlaps the remote range.

ip route get 10.30.8.10
ip -4 addr show wg0
ip route show table all | grep -w wg0

An address that resolves to the physical interface has already answered the question. The tunnel is not dropping anything. The packet never entered it.

Counters Are Evidence, Not a Verdict

wg show reports bytes sent and received per peer, and the two numbers move independently. Take a reading, make one permitted request, then take another reading within the same minute.

wg show wg0 transfer
wg show wg0 latest-handshakes
ping -c 4 10.30.8.10
wg show wg0 transfer

Sends climbing with receives flat is the signature of an unanswered request. It does not say whether the request was filtered, whether the destination was down, or whether the reply left by another route. Those are three investigations that share one symptom. Separate them before changing any configuration.

A fixed byte count is not a success threshold either. Counter values follow the traffic, and treating one number as proof of health produces confident nonsense.

The Peer Checks the Return Packet Itself

The far peer accepts an inner packet only when the source falls inside that peer's allowedips. A route that exists on the sender is not enough. A missing source entry on the receiver drops the return traffic silently.

Host firewalls sit behind that check. A forward rule that permits the tunnel interface but not the inner subnet accepts the handshake and rejects the packet. That looks exactly like a dead peer from the client side. A host with two interfaces can also answer from the wrong source, and the peer then discards the reply it never expected.

Keep the Experiment Honest

Testing a remote-access profile from the same home network it is meant to reach exercises a different path than the intended one. Move to the external network and record its local prefix, so the two runs can be compared.

A small successful exchange does not rule out every path problem either. Larger packets can fail where small ones pass, and a filter that matches on size or protocol can behave differently under load.

Keep the handshake as the known-working stage and move forward from it. The next useful evidence is where one inner request stops, not a fresh set of keys and another round of guessing.