Remove WireGuard Access and Retire the Peer

A WireGuard peer is easy to add for a laptop or a supplier. Months later, the gateway may contain public keys with no obvious owner, and nobody may know whether the saved configuration matches the running interface.

Treat peer ownership and removal as part of the VPN's operating procedure. A successful connection establishes that a configured key can use the tunnel; it does not provide the surrounding record of who should have access and when that access should end.

Give each peer a useful identity record

Record the public key, person or device, business owner, assigned tunnel addresses, permitted purpose and review date. Use distinct credentials for separately managed devices so a lost laptop can be removed without replacing every user's configuration.

Keep private keys out of the inventory, logs and support tickets. WireGuard's quick-start documentation explains the relationship between interfaces, keys and peers. The inventory should identify the configured public key without collecting the material that permits a device to authenticate.

Identify every gateway where the peer is accepted. Include a standby gateway and any configuration repository, management service or deployment template. Removing an entry on the active server is incomplete if a later deployment recreates it.

Understand what AllowedIPs controls

The wg manual describes AllowedIPs as addresses accepted from a peer and destinations directed to that peer. It is part of WireGuard's cryptographic routing configuration. It is not a general application-permission system.

On a client, the configured destinations influence which traffic goes into the tunnel. On the gateway, the peer's address assignment and the host's routing and firewall policy determine a different part of the path. Keep those roles clear when reviewing a split-tunnel design.

For each access group, list the services it may reach and apply the appropriate gateway and application controls. A supplier needing one internal application should not automatically inherit broad administrative access because the tunnel can route an entire subnet.

Check IPv4 and IPv6 consistently. Also record the DNS resolver arrangement and whether internal names are expected to resolve only while connected. A route that works by address can hide a separate name-resolution problem.

Compare the current and persistent states

These read-only commands show selected operational information without requesting private-key output:

sudo wg show wg0 peers
sudo wg show wg0 allowed-ips
sudo wg show wg0 latest-handshakes

Use the actual interface name. Avoid indiscriminate configuration dumps in tickets; some output forms include secret material. Compare the peer list with the authoritative configuration and the ownership register.

A recent handshake helps investigate activity, but an old timestamp does not prove a peer is unnecessary. WireGuard is intentionally quiet when unused, as its quick-start guide explains. A rarely used recovery laptop may legitimately have no recent traffic.

If the host uses wg-quick, review its persistence behaviour. The wg-quick manual states that SaveConfig=true writes current interface state on shutdown and can overwrite file edits made beforehand. Plan removal in both places so one does not reintroduce the other.

Complete a controlled removal

For a planned leaver or supplier departure, identify the exact public key and all gateways accepting it. Preserve the current authorised configuration, confirm an independent administrator route and use the supported management process to remove the peer from runtime and persistence.

Do not restart the whole VPN unnecessarily if the documented tool can apply the required change more narrowly. Conversely, do not treat a runtime change as complete until the saved source has also been corrected. Account for configuration automation and the next gateway restart.

Verify the current peer list and, where authorised, test from the retired device. Confirm that remaining users can still reach their intended services. Test persistence during a suitable planned maintenance event, or inspect the exact configuration that the next start will consume.

Review access beyond the tunnel

Remove or adjust application accounts, SSH keys, shared secrets and supplier permissions separately. A person may retain access through another VPN, a public endpoint or a previously issued application token. VPN removal is one task in offboarding, not evidence that every credential has been withdrawn.

For a suspected lost or compromised private key, follow the incident procedure and review activity during the exposure period. Record the removed key, affected gateways, completion time and verification evidence. Keep the register updated so the next request to remove access starts with a known identity rather than a search through unexplained peer entries.

References

• WireGuard, Quick Start. Accessed 17 October 2026.
• WireGuard, wg manual. Accessed 17 October 2026.
• WireGuard, wg-quick manual. Accessed 17 October 2026.