Handshake Up, Address Gone: Three WireGuard States
A recent handshake proves the peer answered, not that the interface holds its address or that the next packet takes the intended uplink.
WireGuard can hold a fresh handshake and no address at the same time, and that state is coherent rather than contradictory. The handshake is a peer event, the address belongs to the interface, and the route decides which uplink a packet leaves by. Three layers, three owners, and each can fail while the other two look healthy.
Reading them as one status is what turns a two-minute diagnosis into an afternoon of restarting services.
A handshake is a peer event, not an addressing event
WireGuard's handshake proves that the configured peer answered with a valid key and that the session keys are current. It says nothing about the local address on the interface, and nothing about whether any route points there. A helper or network manager assigns the address, while the protocol configuration only names peers and keys. Confusing the two is how a healthy handshake gets read as a working tunnel.
That is why wg show can report a handshake seconds old on an interface that cannot accept a single packet from an application.
A manager recreating the interface can drop the address without touching the peer configuration, and the next handshake succeeds immediately because the keys never changed. The log line about a successful handshake is accurate and irrelevant to the failure.
| Observation | Which layer it belongs to | Wrong conclusion it invites |
|---|---|---|
| Handshake a few seconds old | Peer and keys | The tunnel is usable for application traffic |
Address present on wg0 | Interface configuration | Traffic actually egresses through it |
Route points at wg0 | Forwarding table | The outer packet uses the intended uplink |
The interface address has its own owner
An address on the tunnel device can come from a helper's Address line, from a DHCP client running on the interface, or from a management daemon that creates it at connect time. Whichever it is, that component owns the address and will restore it or not according to its own logic. Reading the address without naming its owner leaves you unable to explain why it vanished.
Two owners on one interface is the classic failure. Starting a helper and a desktop network manager over the same device produces a race where one removes what the other just configured, and the endpoint keeps answering throughout.
Pick one owner and let the other tool observe rather than manage. That decision is worth writing down, because the symptom appears weeks later and looks like a random address loss.
A route chooses an uplink, the interface does not
An inner route pointing at wg0 decides that traffic enters the tunnel. A separate decision sends the encrypted outer packets toward the peer, and on a host with several uplinks that decision comes from the forwarding table and policy rules. A Wi-Fi roam can change the outer path without touching the inner address.
So a working tunnel and an unreachable peer are compatible states, and so are a correct peer and a broken inner route. The three observations have to be taken together, at the same moment, or the comparison is meaningless.
Compare the three states in one pass
Three read-only commands answer the three questions in the order that isolates the failure fastest. Run them without changing anything between them.
ip address show dev wg0
ip route get 10.80.0.1
wg show wg0 latest-handshakes transferThe first shows whether the interface holds an address at all, and the second shows which device a specific destination would use right now. The third reports the last handshake time and the byte counters, which is the only one of the three that describes the peer rather than the local host.
Read the counters as well as the timestamp. A handshake that keeps refreshing while transfer stays flat means the peer answers but nothing useful crosses, which points at routing or an ACL rather than at keys. A timestamp that stops advancing while an address is present points upstream instead. Both readings come from the same line of output, and neither is visible if you only check that a handshake exists.
Correct the specific state that is wrong, then retest the application rather than the tunnel. A recent handshake is peer evidence, and evidence about the peer is not evidence that the next request from your browser will find an address, a route and a working uplink. The wg-quick manual is explicit about which of those the helper sets up and which belong to the protocol.