WireGuard «Required key not available»: las 4 causas reales

En dmesg o 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

o, la que más se cita:

Required key not available

El kernel te dice una cosa precisa: llegó un paquete a una interfaz WireGuard y ninguna clave configurada pudo descifrarlo. La red funcionó. La criptografía, no.

Esa distinción acota enormemente el problema, y explica por qué los reflejos habituales (revisar el firewall o el puerto) casi nunca ayudan aquí. Si el puerto estuviera cerrado, no verías absolutamente nada.

Por qué el mensaje no nombra ningún peer, y nunca lo hará

Un paquete WireGuard que el kernel no puede descifrar es, desde su punto de vista, indistinguible del ruido. No hay ningún campo de remitente en claro que leer. Nombrar un peer obligaría a adivinar, y el protocolo está diseñado para no adivinar, que es también lo que hace que WireGuard permanezca en silencio ante los escáneres de puertos.

Así que el mensaje es honesto, y por sí solo inútil. La información está en otra parte.

Los tres comandos que la localizan

wg show

Lee la línea latest handshake de cada peer. Un peer sin ningún handshake nunca completó uno, lo que apunta a las claves. Un peer con un handshake antiguo y contadores transfer que suben es otro problema.

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

Cruza las marcas de tiempo con tus propios intentos de conexión. Las líneas que solo aparecen cuando intentas conectarte son tuyas. Las que van cayendo sin parar son internet, y son ruido.

wg show wg0 public-key

En las dos máquinas. Es la comprobación que resuelve la causa más frecuente, más abajo.

Causa 1: una clave pública que no es la que crees

Con diferencia, la más frecuente. El servidor guarda una clave que no es la del cliente, o el cliente guarda la antigua del servidor.

La trampa tiene una forma concreta: PublicKey en un bloque de peer debe ser la clave pública de la OTRA máquina, nunca la tuya. Copiar una configuración entre dos clientes y olvidarse de cambiar esa línea crea una entrada de peer que apunta a sí misma, y todos los paquetes fallan.

Compruébalo comparando directamente:

wg show wg0 public-key

Ejecútalo en el servidor y compáralo con la PublicKey del bloque [Peer] del cliente, carácter a carácter. Luego al revés. Las cadenas Base64 difieren en un solo carácter más a menudo de lo que nadie espera, sobre todo tras copiarlas a través de una app de chat que ha recortado algo con toda su buena intención.

Causa 2: una clave precompartida en un solo lado

PresharedKey se mezcla en el handshake. Si está en un lado y no en el otro, o en ambos con valores distintos, las claves derivadas dejan de coincidir.

El síntoma es idéntico al de una clave pública errónea, por eso la gente pasa una hora con la causa 1 antes de dar con esta. Si has añadido una clave precompartida hace poco, revisa los dos extremos antes que cualquier otra cosa. El mecanismo, y cómo añadir una sin quedarte fuera, están en la guía de la clave precompartida de WireGuard.

Causa 3: la clave privada se ha regenerado

Todo lo que vuelve a crear el par de claves invalida cada entrada de peer que hacía referencia a la clave pública antigua: reinstalar el cliente, restaurar un contenedor desde una imagen, ejecutar wg genkey en un script que ya se ejecutó una vez.

La pista es que ayer funcionaba y nada cambió en la configuración. Nada cambió en el archivo, pero la clave que hay detrás sí. Un servidor que se reconstruye una y otra vez (un equipo doméstico reinstalado tras una avería de disco o un contenedor recreado desde una imagen) es el origen habitual; un VPS pequeño con IPv4 pública fija y snapshots conserva la misma clave en el mismo host. Un Contabo Cloud VPS (enlace de afiliado) cuesta 5.50 € al mes con un compromiso de 24 meses y un snapshot incluido (consultado el 17 de octubre de 2026), y Ultahost VPS Basic (enlace de afiliado) cuesta 5.52 $ al mes con un compromiso de 24 meses, con una IPv4 dedicada y garantía de reembolso de 30 días (consultado el 21 de octubre de 2026).

Si de todos modos vas a rehacer el par, genera los dos lados desde la misma fuente. Nuestro generador de configuración WireGuard gratuito crea cada par de claves en tu navegador y escribe los bloques [Peer] del servidor y el archivo de cada cliente a partir del mismo material, de modo que la clave pública que el servidor guarda para un cliente es, por construcción, la que deriva de la clave privada de ese cliente. Añade el nuevo bloque [Peer] al servidor en marcha con wg set o wg syncconf, como se explica en añadir un peer a WireGuard, y el silencio de la entrada antigua desaparece. El generador es gratuito hasta 10 dispositivos; más allá, WireGuard Pro (nuestro propio producto, 9 EUR en un único pago, sin suscripción) sube el límite a 250 y añade un ZIP con el .conf de cada cliente y su código QR en PNG, práctico para configurar una oficina o una familia entera de una vez.

Causa 4: no es tu tráfico en absoluto

Un servidor que escucha en un puerto UDP público recibe paquetes no solicitados. Los escáneres los envían sin parar, y cada uno genera una línea.

Es normal y no requiere ninguna acción. Es ruido de fondo, y solo se convierte en señal cuando coincide con tus propios intentos. Si el volumen te molesta, cambiar el puerto de escucha lo reduce, pero silenciar esa categoría de log eliminaría el único diagnóstico que tienes cuando falla un peer real.

El orden que lo encuentra más rápido

1. wg show en ambos extremos. La ausencia total de handshake confirma un problema de claves y no de enrutamiento.
2. Compara las claves públicas directamente con wg show wg0 public-key, en ambos sentidos.
3. Comprueba si PresharedKey existe en un lado y no en el otro.
4. Mira las marcas de tiempo. Si las líneas aparecen sin que hagas nada, son escáneres.

Si la interfaz ni siquiera llegó a levantarse y la clave se rechazó antes de intentar ningún handshake, el problema es la forma de la clave y no su valor: eso es key is not the correct length or format, un fallo de análisis con causas completamente distintas.

Si el handshake sí se completa y el tráfico sigue fallando, este no es tu artículo: se trata del MTU cuando las páginas se cuelgan, o de AllowedIPs cuando el enrutamiento es incorrecto. La lista de comprobación general está en solución de problemas de handshake.

Ten lo esencial a mano: la WireGuard Cheat Sheet gratuita (PDF de 4 páginas, paga lo que quieras, se aceptan 0 USD) recoge las tablas de keepalive y MTU, los comandos wg genkey/wg pubkey/wg genpsk y las cuatro comprobaciones de una línea que conviene lanzar primero en el servidor cuando un túnel no deja pasar tráfico. El WireGuard Self-Hosting Kit de pago (9 USD) añade una checklist de diagnóstico de 12 causas y 11 plantillas de configuración.