When a WireGuard handshake succeeds but no data moves, the peers have authenticated recently, yet that fact does not show what happened to your test packet. Generate one controlled flow and compare fresh transmit and receive deltas on both peers. The resulting pattern tells you whether to inspect local route and peer selection, the outer path, remote forwarding and return routing, or a later layer such as DNS or MTU.

The complete VPN guide covers every connection stage. This article begins only after latest handshake has advanced for the peer you intend to test.

Key Takeaways

A current handshake authenticates the peers; it does not prove that a chosen application flow uses the tunnel.［1］

Compare counter deltas around one test, never lifetime totals from unrelated traffic.

No local TX points first to local route or peer selection; TX without RX points to a one-way path.

Once TX and RX both grow for the probe, move diagnosis to DNS, MTU, transport, or the application.

Keep private keys, preshared keys, full configurations, and raw diagnostic dumps out of shared evidence.

How do you diagnose it when a WireGuard handshake succeeds but no data moves?

WireGuard's handshake establishes fresh symmetric session keys between peers that know the expected static public keys. Transport data messages are a separate message type and follow after that authenticated exchange.［1］ A current handshake is therefore strong identity and reachability evidence for that moment, but it is not a synthetic transaction through your intended destination.

The wg interface exposes a peer's latest handshake and cumulative transfer bytes.［2］ Those counters are useful only when you note them before and after a narrow probe. A background keepalive, another application, or an earlier transfer can make nonzero totals look reassuring even while the current flow never enters the tunnel.

Cryptokey routing makes destination and source prefixes part of peer selection. An outgoing packet is assigned to a peer based on the destination's allowed prefixes; a received packet is accepted against the sending peer's permitted source prefixes.［3］ A valid handshake with peer A says nothing about a packet that the operating system routes elsewhere or that WireGuard assigns to peer B.

Seven-step data-path check

Step 1: Define one controlled data probe

Choose one destination address and one protocol you are authorized to test. Prefer a service with a known expected response on the remote network, such as an internal gateway address or a controlled web endpoint. Record the exact time, destination, address family, source interface, and expected result.

Avoid beginning with a hostname. DNS introduces a second request, a resolver route, caching, and possibly several IPv4 and IPv6 results. Use a numeric destination first; test the name only after the packet path works.

Record the target peer's latest handshake time and TX/RX totals on both ends immediately before the probe. Then send a small, bounded request and record the same fields again. Do not continuously generate traffic because overlapping probes make deltas ambiguous.

Stop here if the latest handshake is not current for the intended peer. That is a handshake or identity problem, not the post-handshake state addressed here. The handshake-failure guide helps separate reachability from authentication.

Step 2: Read the TX/RX delta matrix

Use direction labels from the test initiator's perspective. “Client TX” means encrypted transport bytes sent by the initiating peer; “server RX” means the matching peer received encrypted bytes. Exact byte totals may include protocol overhead, so seek timing and directional correlation rather than identical numbers.

Fresh observation during one probe	First place to inspect	Why
Client TX does not rise	Client route, source policy, peer selection	The probe did not become transport data for this peer
Client TX rises; server RX does not	Outer endpoint path, stale endpoint, firewall, NAT state	Encrypted data left but did not arrive at the peer
Server RX rises; no forwarded packet appears	Source-prefix acceptance, local input/forward choice, firewall	WireGuard received data but the next local hop failed
Server forwards; no reply returns	Destination service, upstream filtering, NAT or return route	The request left the peer but no usable reply came back
Reply reaches server; client RX does not rise	Return peer selection, allowed source prefix, outer return path	The response did not become received client transport data
Client TX and RX both rise	DNS, MTU, TCP/TLS, or application	The encrypted path carried data in both directions

One row is not a final diagnosis. It is the next evidence boundary. Confirm the same pattern twice with the same probe before changing configuration.

Step 3: If local TX does not move, verify selection

Ask the operating system which route and source address it chooses for the exact destination. An interface can be active and a peer can have a recent handshake while a more specific main-table route, policy rule, local subnet, or another tunnel wins.

Then compare that destination with every peer's AllowedIPs. Overlapping entries or an unexpected narrow prefix can select a different peer. If you operate several peers, record the counters for all plausible peers instead of looking only at the one you expected.

Confirm that the application is not bound to another interface or address and that its network namespace sees the same routes you inspected. Containers, virtual machines, per-app VPN controls, and split-tunnel exclusions can have a different view from the host shell.

Make only one supported route or peer-selection correction. Retest the same probe and restore the original state if the selected interface or counter delta does not change.

Step 4: If data leaves but does not arrive, inspect the outer path

A recent handshake and a lost transport packet can coexist because network state changed after the handshake. The remote endpoint may have roamed, a NAT mapping may have expired, a mobile network may have switched paths, or a firewall may treat later packets differently.

Compare the endpoint address currently recorded by each peer with the intended session, without publishing private addresses unnecessarily. If the roaming peer initiated the recent handshake, the other peer normally learns its most recent authenticated endpoint.［3］ A stale observation from before a network handoff is not sufficient.

Use authorized packet or firewall counters on the outer interfaces to find the first missing direction. Do not expose private keys or disable the host firewall. If a new handshake immediately makes one data probe arrive, record that temporal relationship; it suggests path or state expiry, not a key mismatch.

Step 5: If the remote peer receives data, follow the inner packet

Once server RX rises, decide whether the inner destination is the server itself or beyond it. For a service on the server, verify local input firewall and whether that service listens on the WireGuard address, the expected port, and the expected address family. For a destination beyond the server, verify IP forwarding, the forward firewall, and the intended egress interface.

Next establish how replies return to the client prefix. A NAT design needs a correctly scoped translation rule and state. A routed design needs upstream knowledge of the WireGuard client network. If the destination is another WireGuard peer, the server needs an unambiguous peer mapping in each direction.

Do not add broad NAT automatically. It can make one probe work while hiding an incorrect routed topology. The connected-without-internet checklist covers full gateway, DNS, and dual-stack diagnosis once the counter pattern points there.

Step 6: If both directions move, leave the handshake layer

Fresh client TX and RX increases correlated with the probe show that encrypted transport data moved in both directions. If the user-visible action still fails, stop rotating keys or editing peer identities. Test the next layer.

First compare a numeric address with a hostname. Then compare a very small request with a larger response and repeat separately over IPv4 and IPv6. Small bidirectional traffic followed by a large-transfer stall is evidence for a WireGuard MTU problem, while a name-only failure points to resolver policy. A TCP reset, TLS alert, HTTP error, or application authorization response is also evidence that the tunnel carried the exchange far enough for a later layer to answer.

Application timeouts need correlation. Confirm that the TX/RX increase belongs to this request rather than a keepalive or background process. If possible, pause unrelated traffic or use a unique controlled destination and time window.

Step 7: Preserve evidence and return to the original state

Write down the initial handshake time, four counter snapshots, route result, endpoint observations, and the first hop where evidence disappeared. Keep only the smallest correction that moved that boundary and is valid under the intended design.

Remove temporary routes, firewall rules, packet generators, and test services. If you changed a persistent peer mapping, verify the administrator's source of truth so a restart does not restore the fault. Do not paste wg show all dump; it can contain public identities, endpoints, allowed prefixes, and preshared-key state that reveal more than the investigation needs.

If you suspect identity configuration despite a current handshake, identify which peer and which key generation the handshake actually used. The WireGuard key-mismatch guide explains a safe public-key comparison. Silence or a counter gap by itself cannot tell you which side is wrong.

Can a second tunnel serve as a control test?

When your own peer completes handshakes but carries nothing, an independent tunnel on the same device is a cheap way to split device problems from peer problems. Disconnect your own peer, install AethoVPN, connect to a recommended location, and move real data through it, such as a page load or a short download: if that transfer succeeds, the device and access network can carry tunnelled traffic, and your peer's AllowedIPs, forwarding, or return route becomes the next suspect. AethoVPN shows connection states rather than raw peer counters or packet captures, so the TX/RX delta comparison itself still happens on your own server. Start the 3-day free trial with your email before running the comparison.

Summary

Begin only when the intended peer's latest handshake is current.
Measure fresh TX/RX deltas around one numeric, bounded probe.
No client TX means route or peer selection; one-way deltas locate the missing direction.
After server RX, separate local service delivery from gateway forwarding and return routing.
Once both directions move, diagnose DNS, MTU, transport, or the application instead of the handshake.
Preserve narrow evidence, remove experiments, and never share secret material.

FAQ

Does a recent handshake prove AllowedIPs are correct?

No. The peers can authenticate while the tested destination selects another route or peer, or while an inner source address is not permitted for the receiving peer.

Why are transfer totals nonzero when my test fails?

They are cumulative and may include an earlier session, keepalives, or another flow. Snapshot both ends immediately before and after one controlled request and compare only the delta.

Can a handshake remain recent after the network path changes?

Yes. A path, endpoint, or NAT mapping can change after the last exchange. Correlate endpoint and outer-interface evidence with the exact failed probe.

What does client TX increasing without server RX mean?

It means the local peer formed encrypted transport data, but the remote peer did not record receiving it in that window. Inspect the outer endpoint path and filtering next.

What if server RX increases but the destination sees nothing?

Inspect inner source validation, local input versus forwarding, firewall policy, forwarding state, and egress selection. The encrypted arrival narrows the fault beyond the handshake.

Should I rotate keys when both TX and RX increase?

No. Bidirectional transport data is evidence that the current peer relationship works for that probe. Move upward to DNS, packet size, transport, or application behavior.

Is a keepalive enough to prove application data works?

No. A keepalive maintains state but does not exercise your destination, response size, DNS lookup, or application protocol. Use a separate bounded request.

Disclaimer: This guide provides general technical troubleshooting information. Inspect only systems and traffic you are authorized to administer, minimize captured data, and never disclose private or preshared keys.

Sources:

WireGuard, "Protocol & Cryptography": https://www.wireguard.com/protocol/
WireGuard Tools, "wg(8)": https://git.zx2c4.com/wireguard-tools/tree/src/man/wg.8
WireGuard, "WireGuard: Next Generation Kernel Network Tunnel": https://www.wireguard.com/papers/wireguard.pdf

Sources checked 12 September 2026.

Related Articles:

WireGuard Handshake Succeeds but No Data Moves