WireGuard: Required key not available. Four Causes, and the Error Names None of Them

Affiliate disclosure - This post contains Contabo affiliate links. If you grab a VPS through them, we earn a commission at no extra cost to you.

In dmesg or journalctl -k:

wireguard: wg0: Receiving handshake initiation from peer ... (invalid)
wireguard: wg0: Invalid handshake initiation from 203.0.113.7:51820
wireguard: wg0: Packet has unallowed src IP from peer

or, most often quoted:

Required key not available

The kernel is saying one precise thing: a packet arrived on a WireGuard interface and no configured key could decrypt it. The network worked. The cryptography did not.

That distinction narrows the problem enormously, and it is why the usual reflexes, checking the firewall or the port, almost never help here. If the port were closed you would see nothing at all.

Why the message names no peer, and never will

A WireGuard packet the kernel cannot decrypt is, from its point of view, indistinguishable from noise. There is no plaintext sender field to read. Naming a peer would require guessing, and the protocol is designed not to guess, which is also what makes WireGuard silent to port scanners.

So the message is honest, and useless on its own. The information lives elsewhere.

The three commands that locate it

wg show

Read the latest handshake line for each peer. A peer with no handshake at all never completed one, which points at keys. A peer with an old handshake and rising transfer counters is a different problem.

journalctl -k --since "10 minutes ago" | grep -i wireguard

Correlate timestamps with your own connection attempts. Lines that appear only when you try to connect are yours. Lines that trickle in continuously are the internet, and they are noise.

wg show wg0 public-key

On both machines. This is the check that resolves the most common cause, below.

Cause 1: a public key that is not the one you think

By far the most frequent. The server holds a key that is not the client's, or the client holds the server's old one.

The trap has a specific shape: PublicKey in a peer block must be the OTHER machine's public key, never your own. Copying a config between two clients and forgetting to change that line produces a peer entry pointing at itself, and every packet fails.

Verify by comparing directly:

wg show wg0 public-key

Run it on the server and compare with the PublicKey in the client's [Peer] block, character by character. Then the reverse. Base64 strings differ by one character more often than anyone expects, especially after a copy through a chat client that helpfully trimmed something.

Cause 2: a preshared key on one side only

PresharedKey is mixed into the handshake. Present on one side and absent on the other, or present on both with different values, and the derived keys no longer match.

The symptom is identical to a wrong public key, which is why people spend an hour on cause 1 before finding this. If you added a preshared key recently, check both ends before checking anything else. The mechanism, and how to add one without locking yourself out, is in the WireGuard preshared key guide.

Cause 3: the private key was regenerated

Anything that recreates the key pair invalidates every peer entry that referenced the old public key: reinstalling the client, restoring a container from an image, running wg genkey in a script that already ran once.

The tell is that it worked yesterday and nothing in the config changed. Nothing in the file changed, but the key behind it did.

Cause 4: it is not your traffic at all

A server listening on a public UDP port receives unsolicited packets. Scanners send them constantly, and each one produces a line.

This is normal and requires no action. It is background noise, and it becomes a signal only when it coincides with your own attempts. If the volume bothers you, changing the listening port reduces it, but silencing the log category would remove the only diagnostic you have when a real peer fails.

The order that finds it fastest

1. wg show on both ends. No handshake at all confirms a key problem rather than a routing one.
2. Compare public keys directly with wg show wg0 public-key, both directions.
3. Check whether PresharedKey exists on one side and not the other.
4. Look at the timestamps. If the lines appear without you doing anything, they are scanners.

If the handshake does complete and traffic still fails, this article is the wrong one: that is either MTU when pages hang, or AllowedIPs when routing is wrong. The broader checklist is in handshake troubleshooting.