Recover WireGuard Tunnels From a Dead Windows PC

A laptop dies with three WireGuard tunnels configured, and the configuration files are still on the disk. Copying them to a replacement machine produces a service that starts and then refuses to come up. The files are protected with a key that belongs to the account and machine that created them, so the bytes travel and the ability to read them does not. The walkthrough below goes from locating the file to the option that actually recovers service.

Where the tunnel file lives now

Storage has moved between releases. Older installations kept profiles in the system profile's local application data under a WireGuard\Configurations folder, and current builds use a data directory inside the program files tree. Each tunnel is a single file with a double extension that names the protection:

Get-ChildItem "C:\Program Files\WireGuard\Data\Configurations"

The .dpapi suffix is not decoration. The file is a protected blob, and the service is designed to consume it in exactly that form. The supported way to install a tunnel from it is an elevated call that points at the blob:

$blob = "C:\Program Files\WireGuard\Data\Configurations\hq.conf.dpapi"
wireguard.exe /installtunnelservice $blob

That command succeeds only in the context that can unwrap the blob. It installs a service; it does not decrypt anything for you.

Why the blob will not open elsewhere

The protection derives its key from the user's logon credentials and, depending on the scope chosen, from the machine. Microsoft's documentation for the protection call says the default belongs to the user and machine that encrypted it, and a machine-wide option changes who may unwrap it. In both cases the key lives in operating-system credential material, not inside the file. The ciphertext is portable; the key is not.

Taking ownership of the folder changes an ACL and nothing else. Mounting the old disk in an enclosure and copying the blob to a new PC leaves you with ciphertext whose key was never copied. The failure is a cryptographic one, and no amount of service reinstalling changes it. The new machine has no master key for that account, and the old key store does not travel with the file.

Products that store settings in an obscured file make the contrast clear. A configuration that is merely obfuscated becomes readable once you find the flag that disables the obfuscation; a protected blob stays closed without the key. Confusing the two leads people to look for a decoder that does not exist.

What to try while the old system still boots

If the installation still starts, export the tunnels from the client while signed in as the account that created them. The export produces ordinary configuration files, and that is the point at which a backup becomes portable.

If the disk is readable but Windows will not boot, the protected files are effectively lost. Tools that promise to recover them are either running in the original context, which you no longer have, or asking you to hand over the blob and your old disk image, which is a decision worth pausing over.

Record what you learn either way: the tunnel names, the endpoints and the public keys. Names and endpoints let you rebuild quickly, and public keys let the peer side identify which entry to remove.

Rebuild from the peer side instead

For a peer you control, generate a new key pair and add the new public key to the peer list. For a corporate or hosted endpoint, ask the administrator to issue a new key and remove the old one. That request is the same one you would make after a theft, because a lost disk means the old private key must be treated as exposed.

Then rebuild the tunnel from the values you recorded, and confirm the handshake before you delete anything else. The old entry on the peer should disappear in the same change, so a stolen disk cannot reconnect later.

The lesson belongs in the backup policy rather than in a recovery tool. A WireGuard configuration is a credential: anyone holding the private key holds the peer's identity, and there is no second password in the way. Either export the configuration deliberately and store it with your other secrets, or accept that recovery means reissuing keys, and write down which choice applies to each tunnel.