You set up a WireGuard mesh for your remote sites, it hummed along perfectly for weeks, and then suddenly one node stops responding. You check the firewall, run a ping, and everything looks sane. But when you dig into the handshake logs, you see constant failures. It turns out your peers are drifting apart because they have stopped trusting each other’s timestamps.

The hidden cost of system clock drift

WireGuard uses timestamp-based replay protection for its noise protocol. If your system clock drifts by more than a few minutes—which happens more often than you think on virtualized hardware or servers without constant ntp syncing—the handshake fails. The kernel effectively kills the connection because it thinks the packet is a stale replay from an attacker. I have spent hours debugging firewall rules when the culprit was just a neglected chrony configuration.

wg show wg0 dump

• Check if the handshake timer is frozen or perpetually incrementing
• Verify your local date against a public stratum 1 time source
• Ensure your virtualization host is not pinning the clock to a dead guest state

If you are running containers, this is even more prone to failure since they inherit the host time but might be blocked from updating it. Stop looking for iptables DROP rules and start checking the wall clock. If your peers are outside your control, you have to ensure your own local time is absolute, or your encryption handshake will never clear the gate.

Next time you lose connectivity, don’t just dump the routing table. Check the handshake timestamp, and if it’s drifting, just restart chronyd or update the system time manually before you start tearing down tunnels.