WireGuard Shows No Latest Handshake: What to Check First

An empty latest-handshake field usually means the interface has not completed a handshake since it came up, which says less about the configuration than it appears to. WireGuard stays silent until a packet needs to leave through the interface, so an idle peer with nothing to send reports exactly that. Establish whether anything was actually offered before you inspect keys.

The test is a permitted packet toward a destination the peer should carry. Everything else on that status screen describes intent rather than activity.

An Idle Interface Has Nothing to Report

WireGuard handshakes lazily: the first packet needing the tunnel triggers the exchange, and the interface stays quiet until then. A peer that was configured and never used shows an empty handshake, zero bytes received and a growing gap since the last one. That state is healthy for an idle client and alarming only if you expected traffic to have flowed already. Check the transfer counters too, because they separate nothing-sent from tried-and-failed.

If the counters sit at zero on both sides, the problem is upstream of the tunnel. Nothing reached the interface to trigger anything.

Trigger Traffic the Peer Is Allowed to Carry

Pick an address inside the peer's allowed prefixes, on the local machine, and confirm the routing table would send it through the interface. A destination outside those prefixes produces an ordinary routed request with no WireGuard involvement at all. Use a service that answers quickly, such as a ping or a short TCP connection, so the attempt has a visible beginning and end. Then read the handshake line again instead of watching the screen and waiting.

ip route get 10.60.9.5
ping -c 3 -W 2 10.60.9.5
wg show wg0 latest-handshakes
wg show wg0 transfer

The route query matters more than the ping. If it names the physical interface, the packet never entered the tunnel and the empty handshake is a routing answer rather than a cryptographic one. Repair the route before debugging the peer.

Compare the Key Pair and the Endpoint

Once traffic is genuinely offered, identity is the next check. The local private key must correspond to the public key the far side authorises, the configured remote public key must identify the intended peer, and any preshared key must match on both ends. A single character difference in a base64 key produces a peer that looks configured and never completes an exchange. Compare against the provisioning record rather than regenerating keys, because a new key invalidates every peer that trusted the old one.

The endpoint needs the same scrutiny: hostname, address, UDP port and the family used to reach it. A stale address or the wrong port produces silence rather than a message.

Watch the Outer UDP Path

The handshake travels as UDP toward the endpoint, so the outer path has to carry it. The commands below check whether a listener exists, whether the local stack emitted the datagram, and which endpoint is configured. Run the capture while triggering traffic rather than before it.

ss -lunp | grep 51820
sudo tcpdump -ni eth0 udp port 51820
wg show wg0 endpoints
conntrack -L -p udp | grep 51820

A capture showing the initiation with no reply points outside the machine, because the far end is either not listening, filtered, or addressed incorrectly. A capture showing nothing at all means the packet never left, which returns you to the route and to any socket mark in play. When you administer both ends, correlate the attempt by timestamp with a narrow capture on the server instead of a general one. A TCP port test proves nothing here, since the protocol is UDP only.

Once a handshake appears, test an application over the tunnel, because a completed exchange proves identity and reachability rather than usable throughput or correct DNS. Keep the status output from before and after the change, and the difference becomes your evidence.