WireGuard Peer Gone After Restart: Find the Real Config

A peer you added with wg set answers pings all afternoon and is gone after the reboot. Nothing was corrupted: the kernel never stored that peer anywhere except in the live interface, and whatever recreates the interface on boot rebuilt it from a file you did not touch. The repair is not another wg set. It is finding out which component owns the interface, editing that component's state, and then proving the peer survives the exact lifecycle event that removed it.

Reproduce it once, on purpose

Do not fix a restart problem until you can watch it happen. With console or out-of-band access available, note the peer list, restart through the service that owns the interface, and compare. If the peer is still there, your change already reached persistent state and you are debugging the wrong event.

Write down three facts while you do this: the interface name, the unit or profile that started it, and whether the handshake counter on the surviving peer reset. A reset counter means the interface was destroyed and recreated; an unchanged counter with a missing peer means something edited the configuration underneath you.

Who owns the interface?

WireGuard itself has no daemon and no configuration file. Something above it calls wg on boot, and that something is the source of truth. The usual candidates are [email protected], a NetworkManager connection profile, a distribution-specific network unit, or a management panel that writes its own database.

Ask the system rather than the documentation for your distribution. systemctl status wg-quick@wg0 and nmcli connection show will usually settle it in one command each. If both claim the interface, you have found the bug before editing anything: two owners rewriting the same device on every start, with the last one to run winning.

systemctl status wg-quick@wg0 --no-pager
grep -R "Address\|SaveConfig\|PostUp" /etc/wireguard/wg0.conf
nmcli -g NAME,TYPE connection show
wg show wg0 peers

Runtime state and startup state are not the same file

wg set manipulates the live device through netlink. It does not write /etc/wireguard/wg0.conf, a NetworkManager profile, or a panel's database. A successful wg show afterwards proves the kernel accepted the peer, not that anything will restore it.

There is a second trap in the other direction. wg-quick's SaveConfig option writes the current interface state back to the configuration file when the interface is taken down. With that enabled, an edit made to the file while the interface is up can be overwritten by the shutdown that follows, and you will swear the line was there. If the peer keeps reverting, read the file after a stop, not before.

NetworkManager behaves differently again: it owns the profile and applies it on activation, so a hand-edited .conf next to an active NetworkManager connection is decorative. Pick one owner for the interface and let the other manager leave it alone.

Make the edit land in both places

Edit the persistent state first, then let the owner apply it, then verify the live state. That order means a failure at any step points at one thing instead of three.

# 1. persistent state (wg-quick owner)
sudo vi /etc/wireguard/wg0.conf

# 2. apply through the owner, not by hand
sudo systemctl restart wg-quick@wg0

# 3. verify runtime matches the file
sudo wg show wg0
sudo wg showconf wg0

wg showconf prints the live configuration in the same syntax the file uses, which makes the two directly comparable. Treat that output as secret: it contains private keys, so do not paste it into a ticket or a chat channel. Compare peer public keys and allowed IPs, and check that the peer you removed on purpose is not back.

Prove it survives the lifecycle event

Restart through the owner a second time, then confirm three separate things: the peer appears in wg show, the handshake counter increases after traffic, and the application that depends on the tunnel actually answers. A peer listed with a stale handshake is a routing or key problem, not a persistence problem, and the distinction saves a pointless config edit.

Finally, check what the restart restored. A reboot that resurrects a peer you deliberately removed is the same bug with the opposite sign, and it usually means an old copy of the configuration is still being loaded from somewhere. Record the owner, the file path, the peer public key and the verification commands next to the configuration so the next person does not rediscover this by rebooting a production host.