What a WireGuard handshake timestamp actually tells you

A single line reading latest handshake, two minutes ago, looks like evidence of continuous activity and is weaker than that. It marks the last completed key exchange for one peer, which happens on a fixed rekey timer while traffic flows and stops when the peer goes quiet. Whether that time links a person to anything depends on the identifiers stored beside it and the clocks of both systems. Here is how the record behaves in the two most common stacks, and where reading it goes wrong.

Two records, two different meanings

WireGuard keeps one handshake timestamp per peer, replaced on each rekey, plus byte counters in each direction. OpenVPN typically records a session start, a disconnect and whatever the configured verbosity adds, which makes the unit of the record a session rather than a key exchange.

That difference decides what an absence means:

Why a handshake is not continuous use

WireGuard rekeys roughly every two minutes while there is data to protect, and a peer that goes idle simply stops. So a stale handshake can mean the laptop is asleep, the user stopped working, or the network dropped the packets that would have triggered the next exchange. The timestamp is a lower bound on activity, not a tracker of attention.

The reverse mistake is just as easy. Persistent keepalive traffic will keep the tunnel warm on an idle device, so a recent handshake can appear on a machine nobody has touched for an hour. Byte counters help here, because they distinguish a peer sending real data from one exchanging only keepalives, and they also tell you which direction carried the volume. None of that reveals a destination, a page or a query.

Identifiers travel with the timestamp

A time without an account, a public key or a source address is an orphan. Pair the timestamp with the peer identity and the observation becomes linkable: a public key persists across address changes, while a source address may be shared by many subscribers behind carrier translation.

That asymmetry is what most privacy discussions miss. The address looks anonymous because it is shared, and the key looks technical because it is long, yet the key is the stable identifier. Retaining one field and dropping the other changes the correlation risk without changing the apparent precision.

Correlation itself is the documented concern. Joining a connection time with a provider's login event, a support ticket or a payment record can associate an identity with activity even when no destination was ever written down, which is why the pairing matters more than the formatting.

Cross-system correlation needs clock care

Two systems reporting the same moment rarely agree to the second. One may apply a timezone offset in its output, another may run on a clock several seconds off, and a virtual machine can drift after a suspend.

Before concluding that two events happened together, convert both to the same zone and check the offset in the raw record rather than the display. If the gap you are measuring is smaller than the likely skew, you have no ordering at all.

The practical rule is to keep the precision the troubleshooting task needs and no more. A count of sessions per hour answers an availability question without keeping a per-account history, and an aggregate can be retained far longer than the raw rows it came from.

Read the record with commands, not imagination

Print the fields you are about to reason about, in the units the tool stores rather than the ones a dashboard renders.

These two lines show the handshake age and byte counters for every WireGuard peer, then the same kind of material from an OpenVPN status file:

wg show all latest-handshakes
wg show wg0 transfer
cat /run/openvpn/server.status

Compare the age against the rekey interval before drawing a conclusion, and read the counters together with it. A peer with a recent handshake and almost no transfer is exchanging keepalives, while a peer with a stale handshake and large counters was busy until it stopped. Neither line says what was done, and saying so plainly is more accurate than implying the timestamp proves a visit.