WireGuard «Handshake did not complete after 5 seconds»: 8 causas

Escribes wg show, ves tu peer, y justo debajo está la línea que te arruina la tarde: latest handshake está vacía, o wg-quick te avisa handshake did not complete. Tu túnel está levantado sobre el papel pero no circula tráfico. La buena noticia: WireGuard falla por una lista corta y finita de razones, y aparecen en un orden predecible. Esta guía recorre ese orden de lo más común a lo más raro, para que dejes de adivinar y lo arregles en minutos.

WireGuard es silencioso por diseño - no envía nada hasta que hay datos que transportar, y nunca registra un amable «connection refused». Ese silencio es lo que hace que un handshake fallido parezca misterioso. Casi siempre es un problema de alcanzabilidad de red (firewall, puerto, NAT, enrutamiento), no de criptografía. Recorre la lista de arriba abajo y lo cazarás.

¿Poco tiempo? Dos causas explican la mayoría de handshakes fallidos: un puerto UDP que nunca llega al servidor (firewall cerrado, redirección ausente o CGNAT en su conexión), y después, con el túnel levantado, un MTU demasiado alto. El verificador de puerto WireGuard le indica si está detrás de CGNAT y escribe las reglas de redirección y de firewall para su sistema; la calculadora de MTU da el valor que debe poner cuando el handshake funcione.

¿No sabes cuál de las dos es? Nuestro verificador de puerto WireGuard gratuito compara la dirección WAN de tu router con tu IP pública: en menos de un minuto indica si estás detrás de un CGNAT (ninguna redirección funcionará) o si basta con una redirección y una regla de cortafuegos.

¿Detrás de CGNAT? Ninguna redirección de puertos ni regla de firewall por tu parte puede abrir un camino hacia un servidor en casa. La salida habitual es ejecutar el servidor WireGuard en un VPS con su propia IPv4 pública, como un VPS Cloud de Contabo (enlace de afiliado), desde 5,50 € al mes con un plazo de 24 meses (precio consultado el 17 de octubre de 2026). Si prefieres un proveedor estadounidense con 30 días de devolución, el VPS Basic de Ultahost cuesta 5,52 $ al mes a 24 meses (1 GB de RAM, IPv4 dedicada, leído el 21 de octubre de 2026), suficiente para un servidor WireGuard de pocos dispositivos. ¿Proveedor sin elegir? Comparativas: mejor VPS para una VPN y Contabo vs Hetzner vs OVH, al precio realmente facturado. Otra opción: HostPapa Unmanaged VPS Lite (enlace de afiliado) por 2,95 $ al mes con un plazo de 3 años, luego a la tarifa normal (1 núcleo, 1 GB de RAM, 25 GB NVMe, acceso root por SSH, garantía de reembolso de 30 días, consultado el 28 de octubre de 2026).

¿Aún no has elegido el servidor? Nuestra clasificación de los VPS más baratos para WireGuard compara lo que cada proveedor cobra de verdad por un servidor usable.

La línea de log exacta: "Handshake for peer 1 did not complete after 5 seconds"

Si has buscado el error palabra por palabra, este es el mensaje que tienes delante. Lo imprime el módulo del kernel de Linux (una vez activado el log de depuración), y wireguard-go, la implementación en espacio de usuario que hay detrás de las apps de Windows, macOS y Android, imprime una versión casi idéntica:

wireguard: wg0: Handshake for peer 1 (203.0.113.10:51820) did not complete after 5 seconds, retrying (try 2)
wireguard: wg0: Handshake for peer 1 (203.0.113.10:51820) did not complete after 20 attempts, giving up

Cómo leerlo:

• "after 5 seconds" no es un ajuste que puedas cambiar. Es el timeout de reintento fijo de WireGuard (REKEY_TIMEOUT, 5 s en el código fuente). Tu peer envió una iniciación de handshake y no recibió ninguna respuesta válida dentro de ese margen.
• "retrying (try 2)" significa que sigue intentándolo. WireGuard reenvía durante unos 90 segundos en total.
• "did not complete after 20 attempts, giving up" es el final de ese bucle. El peer se queda en silencio hasta que nuevo tráfico intenta cruzar el túnel, lo que arranca una ronda nueva.
• Failed to send handshake initiation: no known endpoint for peer es un caso distinto: ese lado no tiene Endpoint = para el peer, así que no puede iniciar nada y solo puede esperar a que le contacten. Normal en un servidor; un error de configuración en un cliente.

En Linux, el módulo del kernel no registra nada por defecto. Para ver estas líneas:

echo module wireguard +p | sudo tee /sys/kernel/debug/dynamic_debug/control
sudo dmesg -w | grep wireguard

El mensaje solo demuestra una cosa: la iniciación salió y no volvió nada válido. No dice por qué. Las causas de abajo, en orden, son el porqué.

Primero, lee el estado real con wg show

Antes de cambiar nada, mira lo que WireGuard ya te dice. En ambos extremos:

sudo wg show

Estás leyendo tres cosas:

• latest handshake - vacío o más viejo de ~2 minutos = túnel caído. Sano = en los últimos 120 segundos.
• transfer - 0 B received significa que tus paquetes nunca volvieron. Enviado-pero-nada-recibido es la firma de un firewall o NAT de un solo sentido.
• endpoint - en el servidor, debe mostrar la IP:puerto pública actual del cliente en cuanto llega un paquete. Si nunca se rellena, la iniciación del cliente no te alcanzó.

Mantén este terminal abierto. Tras cada solución de abajo, vuelve a ejecutar wg show y vigila la línea latest handshake. Es tu única fuente de verdad - no el icono de conexión, no la app.

wg show latest-handshakes - la forma legible por máquina

Un wg show a secas imprime un latest handshake: 1 minute, 12 seconds ago pensado para el ojo humano. Cómodo de leer, inservible en un script. El manual wg(8) permite añadir un atributo para acotar la salida:

show { <interface> | all | interfaces } [public-key | private-key | listen-port |
      fwmark | peers | preshared-keys | endpoints | allowed-ips |
      latest-handshakes | persistent-keepalive | transfer | dump]

Así que la forma de referencia es:

sudo wg show wg0 latest-handshakes

Imprime una línea por peer: la clave pública en base64 del peer, un tabulador, y luego el último handshake en segundos desde la época Unix. Es literalmente lo que hace la herramienta: en wireguard-tools, src/show.c contiene printf("%s\t%llu\n", key(peer->public_key), peer->last_handshake_time.tv_sec);:

xTIBd0Kx3Hs9tPmVvQ4ZlLxYcE8nRr2A6WKsPqUvT1s=	1750684173
9QzrN7bLyF0mXaHcJdSoEuIgYkTvW3pB5nRfZ1AhQ0M=	0

Dos cosas que conviene saber sobre ese número:

• Un 0 significa que ese peer nunca ha completado un handshake desde que subió la interfaz. No es una marca de tiempo caduca: es una marca ausente. Ese es justo el estado que estás depurando en esta página.
• Es un tiempo de época absoluto, no una antigüedad. Réstalo de date +%s para obtener los segundos transcurridos desde el último handshake:

now=$(date +%s)
sudo wg show wg0 latest-handshakes | while read -r peer ts; do
  if [ "$ts" -eq 0 ]; then
    echo "$peer nunca"
  else
    echo "$peer $((now - ts))s"
  fi
done

Dos detalles que muerden al escribir el script. wg show all latest-handshakes antepone el nombre de la interfaz como primera columna separada por tabulador, así que tu read necesita una tercera variable. Y wg show wg0 dump te da la misma marca de tiempo junto al endpoint, los allowed-ips y los contadores de transferencia en una línea por peer separada por tabuladores: esa es la forma que hay que parsear si construyes un monitor de verdad y no un one-liner.

Cualquier valor por encima de ~180 segundos en un peer que debería estar activo significa que el túnel está caído. Ese es el umbral para alertar, y el resto de esta página es la lista ordenada de por qué se cayó.

Causa 1 - El puerto UDP está bloqueado (el culpable n.º 1)

WireGuard habla UDP en un único puerto - 51820 por defecto. Si ese puerto está filtrado en algún punto de la ruta, el paquete de iniciación muere y obtienes exactamente tu síntoma. Para entender ese valor por defecto, cómo cambiarlo y abrirlo correctamente, consulta qué puerto usa WireGuard y cómo abrirlo. Normalmente hay dos firewalls que comprobar, y la gente olvida el primero:

Firewall del proveedor cloud (el más olvidado). Contabo, Hetzner, OVH, AWS - todos tienen un firewall de red o grupo de seguridad delante de tu VPS. Una regla que permita UDP 51820 desde cualquier lugar debe existir ahí, separada del firewall del sistema. En la mayoría de imágenes de VPS de Contabo no hay firewall de proveedor por defecto (bien), pero si activaste uno, añade la regla UDP.

Firewall del sistema en el servidor. Comprueba y permite:

# ufw (Debian/Ubuntu)
sudo ufw allow 51820/udp
sudo ufw reload

# firewalld (Rocky/Alma/Fedora)
sudo firewall-cmd --add-port=51820/udp --permanent
sudo firewall-cmd --reload

Prueba rápida de que el puerto es alcanzable desde fuera - desde tu máquina cliente:

# envía una sonda UDP; "open|filtered" sin respuesta no es concluyente,
# pero "open" o un paquete devuelto confirma la alcanzabilidad
nc -u -z -v IP_DE_TU_SERVIDOR 51820

Prueba más limpia: ejecuta sudo tcpdump -n -i eth0 udp port 51820 en el servidor, luego conecta desde el cliente. Si ves paquetes entrantes, el puerto está abierto y pasas a la siguiente causa. Si no ves nada, el paquete se descarta antes de llegar a WireGuard - quédate en esta causa.

¿No llega nada y el servidor está en casa? Comprueba el CGNAT

Si el «servidor» es una Raspberry Pi, un NAS o un PC en tu conexión de casa, un tcpdump vacío a menudo no tiene nada que ver con tu cortafuegos. Muchos operadores (casi todos los routers 4G/5G y cada vez más tarifas de fibra) colocan a sus clientes detrás de CGNAT: tu router comparte una sola IPv4 pública con otros abonados, así que ninguna redirección de puertos podrá hacer llegar un paquete UDP entrante a tu máquina. Compara la dirección WAN que muestra tu router con lo que devuelve curl -4 ifconfig.me. Si no coinciden, o si el router muestra una dirección en 100.64.0.0/10, estás detrás de CGNAT y el handshake no puede completarse con esta configuración.

Tienes tres salidas: pedir una IPv4 pública a tu operador (algunos la dan gratis, otros la cobran, muchos se niegan), usar IPv6 de extremo a extremo si ambos lados lo tienen, o poner el servidor WireGuard en un VPS pequeño con su propia IPv4 pública y, si aún necesitas llegar a la máquina de casa, conectarla al VPS como cliente. La guía de CGNAT explica el túnel inverso, y nuestro generador de configuración WireGuard gratuito escribe los archivos de servidor y cliente con claves que coinciden.

¿No sabes si una redirección de puertos puede funcionar en tu conexión? Nuestro verificador de puerto WireGuard gratuito compara la dirección WAN de tu router con tu IP pública, detecta el CGNAT, escribe las reglas de redirección y de cortafuegos de tu instalación y da la prueba tcpdump que demuestra que los paquetes llegan al servidor.

¿Funciona en casa pero falla en el Wi-Fi de un hotel, una oficina o un campus?

Entonces el servidor está bien y la red en la que se encuentra bloquea el UDP, o reconoce WireGuard y lo corta. La prueba con tcpdump de arriba solo no muestra nada cuando está en esa red. Si el servidor es suyo, pase ListenPort (y el Endpoint del cliente) a UDP 443, el puerto que ya usa HTTP/3, que atraviesa la mayoría de los filtros por puerto; nuestra guía del puerto de WireGuard explica el cambio. Si solo necesita una VPN que funcione en esa red y no gestiona ningún servidor, una aplicación VPN con modo de ofuscación envuelve el túnel por usted: Proton VPN ofrece Stealth, en todos los planes, incluido el gratuito, y NordVPN ofrece NordWhisper, que hace que el tráfico VPN parezca tráfico web normal (enlaces de afiliado). Frente a la inspección profunda de paquetes, consulte la guía anti-DPI.

Plan de pago, Black Friday 2026: la oferta para socios de Proton, comprobada el 28 de octubre de 2026, es VPN Plus a 2,49 $/mes durante 2 años (59,76 $ los primeros 24 meses, después 83,88 $ al año), con garantía de reembolso de 30 días y 10 dispositivos. La página de pedido muestra el precio de tu país, y Proton no publica fecha de fin.

Causa 2 - Endpoint incorrecto en el cliente

El bloque [Peer] del cliente necesita la IP pública real del servidor (o su nombre DNS) y el ListenPort exacto:

[Peer]
PublicKey = CLAVE_PUBLICA_SERVIDOR
Endpoint = 203.0.113.10:51820
AllowedIPs = 0.0.0.0/0

Errores frecuentes que producen un handshake muerto:

• El Endpoint apunta a la IP LAN privada del servidor (10.x / 192.168.x) en lugar de la pública.
• Una errata en el puerto, o el servidor escucha en realidad en otro ListenPort.
• La IP pública del servidor cambió (algunas reinstalaciones de VPS la reasignan). Confirma con curl -4 ifconfig.co en el servidor, luego compara con el Endpoint del cliente.

El bloque del peer en el servidor no lleva línea Endpoint (el servidor la aprende cuando llega el paquete del cliente) - añadir una ahí es un error de copiar-pegar frecuente.

Causa 3 - AllowedIPs incorrectos

AllowedIPs es una tabla de enrutamiento criptográfica, no una lista de permisos, y un error rompe en silencio el tráfico de vuelta:

• En el servidor, el AllowedIPs del peer debe listar solo la dirección de túnel de ese cliente, p. ej. 10.66.66.2/32. Si dos peers comparten un rango que se solapa, el servidor envía las respuestas al equivocado y el handshake «se completa» y luego muere.
• En el cliente, AllowedIPs = 0.0.0.0/0 enruta todo por el túnel (VPN completa). Para split tunneling, lista solo las subredes que realmente enrutas - mira nuestra guía de enrutamiento en split-tunnel.

Un handshake que tiene éxito brevemente y luego se cala es la firma clásica de AllowedIPs que se solapan en el servidor. Haz único el rango de cada peer.

¿Necesitas excluir tu LAN o una sola dirección de un túnel completo? AllowedIPs no tiene sintaxis de «excepto», así que nuestra calculadora de AllowedIPs gratuita convierte «todo excepto X» en la lista mínima de rangos IPv4 e IPv6 para pegar.

Causa 4 - Timeout NAT (funciona 2 minutos, luego muere)

Si tu cliente está detrás de NAT (router doméstico, 4G/5G, Wi-Fi de hotel) y el enlace queda inactivo, el router elimina el mapeo UDP. El servidor ya no tiene ruta de vuelta al cliente y el handshake expira en silencio. La solución vive en el peer que está detrás del NAT:

[Peer]
PublicKey = CLAVE_PUBLICA_SERVIDOR
Endpoint = 203.0.113.10:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

PersistentKeepalive = 25 envía un paquete diminuto cada 25 segundos, manteniendo abierto el mapeo NAT. Veinticinco segundos está por debajo de todo timeout NAT común. Añádelo en clientes nómadas y en cualquier peer detrás de un router restrictivo. El peer del servidor normalmente no lo necesita.

Causa 5 - El reenvío IP está apagado en el servidor

Si el handshake se completa pero no alcanzas Internet por el túnel, el servidor no reenvía paquetes entre la interfaz WireGuard y eth0. Actívalo:

echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-wireguard.conf
sudo sysctl --system

Confirma: sysctl net.ipv4.ip_forward debe devolver 1. Combínalo con la regla de masquerade en tu PostUp (las plantillas de configuración listas para usar incluyen estas líneas correctamente):

PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

Causa 6 - Desfase de reloj

El handshake de WireGuard usa marcas de tiempo para bloquear ataques de repetición. Si el reloj del servidor se desvía más de un par de minutos - común en imágenes de VPS recién creadas o VM que se pausaron - los handshakes se rechazan por caducados. Corrige el reloj:

sudo timedatectl set-ntp true
timedatectl status   # System clock synchronized: yes

Esta es traicionera porque todo lo demás parece perfecto. Si triple-comprobaste el puerto, las claves y el enrutamiento y sigues sin nada, revisa el reloj antes de desesperar.

Causa 7 - Claves no coincidentes (comprueba esto al final)

La gente va primero a las claves; compruébalas al final, porque un error de clave es más raro que las seis causas anteriores y produce el mismo síntoma. La regla es simple:

• La [Peer] PublicKey del servidor = la clave pública derivada de la PrivateKey del cliente.
• La [Peer] PublicKey del cliente = la clave pública derivada de la PrivateKey del servidor.

Regenera y vuelve a derivar para asegurarte:

# en cada máquina, deriva la clave pública de su propia clave privada
echo "CLAVE_PRIVADA_DE_ESTE_HOST" | wg pubkey

Compara esa salida con la PublicKey que el otro lado tiene para ti. Una sola clave invertida o truncada rompe el handshake por completo. De paso, una PresharedKey (si se usa) debe ser idéntica en ambos peers - una diferencia ahí también mata el handshake. Qué protege de verdad la clave precompartida, y cómo añadirla sin cortar un túnel activo, está en la guía de la clave precompartida de WireGuard.

Para descartar las claves de una vez, nuestro generador de configuración WireGuard gratuito crea en tu navegador un par de claves nuevo para cada lado y coloca cada clave pública en el bloque [Peer] del otro, con una PresharedKey idéntica en ambos extremos.

Causa 8 - El MTU rompe el túnel justo tras el handshake

En rigor, el MTU rara vez bloquea el handshake (sus paquetes son pequeños). Pero suele romper cosas en cuanto fluye tráfico real: el handshake se completa, el ping funciona, luego las páginas web se cuelgan para siempre. Eso es fragmentación. Baja el MTU del cliente:

[Interface]
MTU = 1380

Encuentra el valor correcto con un ping «do-not-fragment» a la IP de túnel del servidor, reduciéndolo hasta que pase:

ping -M do -s 1372 10.66.66.1

1420 sirve para la mayoría de enlaces de fibra; 1380 es un valor por defecto seguro; PPPoE y algunos operadores móviles necesitan 1280. Nuestra guía de plantillas de configuración explica el ajuste del MTU por tipo de enlace. Si el túnel conecta pero se cuelga con transferencias grandes, la guía dedicada arreglar el MTU de WireGuard muestra cómo medir el valor exacto con un ping sin fragmentación y ajustarlo por tipo de enlace.

Para obtener el valor en vez de adivinarlo, la calculadora de MTU de WireGuard gratuita parte de la mayor carga útil que pasó tu ping sin fragmentación (o solo de tu tipo de enlace) y escribe la línea MTU = de tu configuración.

El orden de diagnóstico en 60 segundos

Cuando un handshake falla, ejecuta esta secuencia exacta y detente en lo primero que esté mal:

1. wg show en ambos lados - ¿hay algún latest handshake, algún byte received?
2. tcpdump udp port 51820 en el servidor mientras el cliente conecta - ¿llegan paquetes?
3. Si no llega ningún paquete → firewall / puerto / Endpoint (causas 1-2).
4. Si llegan paquetes pero ninguna respuesta vuelve → AllowedIPs del servidor, NAT, ruta de vuelta (causas 3-4).
5. Si el handshake se completa pero no hay Internet → ip_forward + masquerade (causa 5).
6. Si todo parece correcto y aún nada → desfase de reloj, luego claves, luego MTU (causas 6-8).

Este orden sigue el recorrido del paquete, de la accesibilidad al enrutamiento y luego a las causas menos evidentes - recórrelo de arriba abajo y no perderás tiempo.

¿Quieres este orden en una sola página imprimible? La lista de diagnóstico de nuestro WireGuard Self-Hosting Kit de pago (9 USD, en inglés) lo amplía a 12 causas, cada una con el comando que la confirma y la solución, más una tabla para leer la salida de tcpdump. Los pasos de arriba siguen siendo gratuitos y completos para las 8 causas tratadas aquí.

Constrúyelo bien desde el principio

La mayoría de handshakes fallidos vienen de coser a mano una config con tres tutoriales contradictorios. Partir de una base sana en un VPS limpio elimina la mayoría de las sorpresas. Un Contabo Cloud VPS 4 a 5,50 €/mes te da una IPv4 pública, root completo, y ningún firewall de proveedor que combatir - exactamente las condiciones donde WireGuard «simplemente funciona». Sigue la configuración Contabo + WireGuard paso a paso y pega una config verificada de la guía de plantillas, y partes de líneas que se sabe que encajan entre sí.

Si prefieres rehacer ambos extremos desde cero, nuestro generador de configuración WireGuard gratuito crea las claves en tu navegador y escribe configuraciones de servidor y de clientes que encajan: claves públicas, AllowedIPs y Endpoint coinciden al primer intento.

Una VPN cambia su IP. No cambia su navegador.

Un túnel sustituye la dirección que ve un servicio. No cambia nada de lo que su navegador anuncia por su cuenta - fuentes, pantalla, zona horaria, pila gráfica - y esa combinación suele bastar para reconocerle de una sesión a otra.

Mida su huella de navegador - medición pasiva, sin preguntas, sin cuenta, sin correo electrónico.

Para profundizar

• PersistentKeepalive: qué hace de verdad el ajuste de 25 segundos
• WireGuard multihop: encadenar dos servidores autoalojados
• WireGuard detrás de CGNAT: por qué el handshake nunca llega
• WireGuard en Windows: configuración paso a paso
• WireGuard en iPhone y iPad: la configuración completa en iOS
• Auto-alojar VPN en Contabo: guía completa de WireGuard 2026
• Plantillas de configuración WireGuard listas para usar 2026
• Fugas DNS en WireGuard: detectar, diagnosticar, eliminar
• Kill-switch WireGuard en Linux: iptables + systemd
• VPN en split-tunnel con tablas de enrutamiento
• Glosario de VPN auto-alojada - AllowedIPs, MTU, NAT explicados
• PiVPN en 2026: la forma más sencilla de autoalojar WireGuard u OpenVPN

Fuentes y referencias:

• Whitepaper de WireGuard - Jason A. Donenfeld
• Quickstart de WireGuard y docs de wg-quick
• Páginas de manual wg(8) y wg-quick(8)
• Arch Wiki - solución de problemas de WireGuard

Publicado el 2026-06-23. Comandos escritos para servidores Debian 12 y Ubuntu 24.04 a partir de la documentación oficial de WireGuard; no tenemos un banco de pruebas con varios clientes. Tus condiciones de enlace pueden variar - confirma siempre con wg show y tcpdump antes de dar por definitiva una solución.

Recordatorio: ejecutar WireGuard y auto-alojar una VPN es legal en la UE, EE. UU., Canadá. VPNSmith publica este contenido con fines educativos.

También conviene auditar donde residen las claves: un aviso de CISA de julio de 2026 cubre un fallo de RouterOS que permite leer una clave privada WireGuard estática desde el propio router. Consulta por qué desactivar la API no lo deshace.

Si el túnel sí se establece y aun así « no funciona », la causa suele estar fuera del handshake: por qué una VPN conectada puede ser rechazada de todas formas separa el fallo de conexión del rechazo por procedencia, y trata también los casos de wifi frente a ethernet y de iPhone.