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. The public key you pass is the 32-byte
Curve25519 key printed as 44 base64 characters, which is why a peer is identified by that string
and not by a name: WireGuard stores no name for it.
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. The kernel implementation accepts up to 1 048 576 peers per
device, so the limit you hit first is your own ability to tell them apart, not the protocol's.
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 revocation is not quite instantaneous, and the delay is bounded by the protocol's own timers.
A session key is rejected after 180 seconds (REJECT_AFTER_TIME), and a new handshake is normally
initiated after 120 seconds (REKEY_AFTER_TIME). So a session already established when you removed
the peer can keep carrying traffic for up to three minutes before the kernel drops it. If that
window matters, bring the interface down rather than waiting it out.
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→
