You removed the peer. wg show confirms it is gone. A week later the laptop you revoked connects
again, and nothing in your logs explains it.
Nothing went wrong. WireGuard simply has two states, and the command you used only changed one of them.
The two states
| what it is | what changes it | |
|---|---|---|
| running state | what the kernel currently accepts | wg set, wg syncconf |
| configuration file | what gets loaded on the next start | your editor, wg-quick save |
wg set wg0 peer PUBLIC_KEY remove acts on the first. It is immediate, it leaves every other peer
connected, and it never touches /etc/wireguard/wg0.conf.
So the next wg-quick down wg0 && wg-quick up wg0 — a reboot, a package upgrade, a systemd
restart you did not think about — reads a file that still contains the peer, and puts it back.
Nobody is notified. The access simply resumes.
Removing it for good
Two orders of operation, and the second is the one to prefer.
The quick one, when the file has nothing you care about:
sudo wg set wg0 peer PUBLIC_KEY remove
sudo wg-quick save wg0
wg-quick save writes the running state back to the file. It works — and it rewrites the file from
the kernel's point of view. Your comments disappear. On a server with a dozen peers, those
comments are usually the only record of which peer is which laptop. Losing them turns a readable
config into a list of anonymous public keys.
The one to prefer, which keeps the file authoritative:
sudo nano /etc/wireguard/wg0.conf # delete the whole [Peer] block
sudo wg syncconf wg0 <(wg-quick strip wg0)
wg syncconf applies the file to the running interface without bringing it down: only what
changed is affected, and the other tunnels keep their sessions. wg-quick strip removes the
directives the kernel does not understand — Address, DNS, PostUp — and prints what remains.
The distinction matters on a server with several clients: wg-quick down && up drops everyone for
a couple of seconds to revoke one peer.
Two flat keys on a single ring, hanging from a pale metal plate screwed to a light wooden door. The upper key carries the engraved initials « R.M.I. ». Warm tones, visible wood grain.
Verify in both places, not one
sudo wg show wg0 peers # what the kernel accepts now
grep PublicKey /etc/wireguard/wg0.conf # what loads next time
A key absent from the first and present in the second is a revocation with an expiry date. It is the exact situation this article exists for, and it is invisible until the day the interface restarts.
What revoking does not do
Removing the peer means the server refuses the handshake. The key material on the lost device becomes useless against this server. That is real, and it is where the effect stops.
The configuration file is still on that device. So is its private key, and whatever else the device held — a session that was still open, a password manager left unlocked, the mailbox that can reset your other accounts. Revoking the tunnel is the right first move. It is not the whole response, and treating it as such is how people end up perfectly confident and still exposed.
Situate your own attack surface — 10 questions, about three minutes, no account, no email, nothing stored. The result names the one change that reduces your exposure the most, and for someone who self-hosts it is rarely another firewall rule.
In short
| What you did | What it actually changed |
|---|---|
wg set … peer … remove | the running state only — reverts on restart |
wg-quick save | the file too, at the cost of your comments |
edit the file, then wg syncconf | both, without dropping the other peers |
| revoked after losing a device | the tunnel, not what the device still holds |
One line worth keeping: a peer removed from memory and left in the file is not removed, it is postponed.
★ Nuremberg GDPR datacenter · ✓ Dedicated IPv4 included · 200+ Mbps guaranteed
Self-host your VPN on your own VPS → ContaboFull root access · public IPv4 · pick your region→
