Copied WireGuard Profile: Why Both Devices Fail

The tunnel worked on the laptop, so the config file went onto the phone and the tablet, and now the handshakes come and go on all three. Nothing was mistyped and the server configuration was not edited. A WireGuard profile is not an account with a password that several devices may use; it is a key pair, and the public half is the only thing that identifies a peer. Copying the file copies the identity, so the server is now trying to keep a single endpoint relationship for several devices that all claim to be the same one. From the server's side there is no second device to notice, only a peer whose address keeps moving.

Start With the Handshake Log on Each Device

Open the client on each device and record the last handshake time and the current endpoint before changing anything. On a healthy setup those values stay stable while a device is in use; on a duplicated identity the timestamps alternate, and the endpoint recorded on the server may describe a different device from the one holding the profile. That alternation is the signature, and it explains why the symptom looks like flaky connectivity rather than a configuration error. The devices are not broken; they are interrupting each other.

Do the reading on the devices themselves, so each observation is attached to a specific machine. A timestamp copied from a support chat loses that attachment and is worth very little afterwards.

Confirm Whether Two Devices Share One Identity

Compare the public keys, never the private ones. The public key is derived from the private key, so two profiles containing the same private key produce the same public key and are indistinguishable to the server. If two devices report the same public key, the question is settled and no amount of keepalive tuning will help. Two different keys with flaky handshakes point somewhere else entirely, which is why the comparison has to come before any change.

wg show wg0 public-key
wg show wg0 latest-handshakes
wg show wg0 endpoints
wg show wg0 transfer

These commands print only public material and counters, which is all a support conversation needs. A server peer entry with one public key and an endpoint that keeps moving between two networks is the expected result of the duplication, because an authenticated packet from a new source updates where traffic is sent. That behaviour is the protocol working as designed, which is why it is so easily mistaken for a network fault.

Provision a Second Identity Properly

Generate a new key pair on the device that needs one, then add the resulting public key to the server as a separate peer with its own allowed addresses. The private key should be created on the device and stay there; a key generated elsewhere and pasted in has travelled through at least one extra place, and that trip is now part of the trust story.

umask 077
wg genkey > newdevice.key
wg pubkey < newdevice.key

The server side needs the public key plus an allowed-address assignment that does not collide with the original device. A profile that keeps the old tunnel address while presenting a new key produces a peer the server may accept and then route incorrectly, which is a subtler failure than a refused handshake. Check the address assignment before connecting, not after the first confusing packet loss.

Retire the Duplicate Without Breaking the Original

Once the new identity works, remove the copied profile from the original device's neighbours rather than deleting the server entry the original still uses. If the copy may have been exposed, revoke immediately instead, then reissue; convenience is not a reason to leave a shared secret in circulation.

A managed service that genuinely supports several devices per subscription will tell you so and issue separate credentials from its own interface. Manual duplication of one profile is never that model, even when the service's branding suggests unlimited devices.

Test Both Devices Separately and Together

Verify each device on its own first: handshake, transfer counters moving, and a destination that only the tunnel can reach. Then run both at the same time and watch the server's view of endpoints; two distinct keys should produce two stable peer entries rather than one that jumps.

Keep the new public keys with the deployment notes and record which device holds which. Without that list, the next person to copy a profile repeats the same failure, and the alternating handshakes will be blamed on the network again.