Cómo solucionar fallos de handshake de WireGuard (guía de resolución)

El handshake de WireGuard es el intercambio de claves inicial que tiene que completarse con éxito antes de que pueda circular cualquier tráfico por el túnel. Cuando falla, obtienes una conexión que parece correctamente configurada pero que nunca llega a transmitir datos, y los mensajes de error suelen ser poco útiles, solo un “handshake did not complete” o directamente nada. Así se recorren las causas reales en el orden en que es más probable que sean el problema.

Qué hace realmente el handshake

WireGuard usa un marco criptográfico llamado Noise para establecer una sesión segura entre tu dispositivo y el servidor antes de que circule ningún tráfico real. Ambos lados necesitan alcanzarse por UDP, verificar mutuamente sus claves públicas y completar este intercambio en cuestión de segundos. Si alguna parte de ese camino está bloqueada, mal configurada o no coincide, el handshake falla en silencio y reintenta en bucle en lugar de mostrar un error claro, por lo que diagnosticar la causa requiere una comprobación metódica y no la lectura de un mensaje de registro evidente.

Paso 1: confirmar que la interfaz está realmente activa

Ejecuta sudo wg show en Linux, o comprueba el estado de conexión de tu app en otras plataformas, para confirmar que la interfaz de WireGuard está activa. Si la interfaz en sí no está activa, el problema está en tu archivo de configuración o en la configuración de la app, no en la ruta de red, y el resto de esta resolución de problemas aún no aplica. Corrige primero cualquier error señalado en esta fase.

Paso 2: comprobar si hay un puerto UDP bloqueado

WireGuard funciona sobre UDP, normalmente por el puerto 51820 por defecto, aunque los proveedores pueden usar uno distinto. Algunas redes de hoteles, aeropuertos, empresas y campus bloquean o restringen mucho el tráfico UDP saliente en particular, ya que el UDP es menos habitual en la navegación típica y se asocia más con VPN y videojuegos. Prueba a cambiar temporalmente a un punto de acceso móvil para descartarlo: si el handshake se completa al instante en otra red, el cortafuegos de la red original es el verdadero problema, y ningún ajuste de configuración por tu parte lo va a arreglar. Algunos proveedores ofrecen una opción de ofuscación basada en TCP específicamente para estas redes restrictivas, que merece la pena probar si el UDP está bloqueado de forma constante donde estás.

¿Quieres comparar todos los VPN uno al lado del otro? Consulta nuestra tabla comparativa completa con puntuaciones en 18 criterios.

Paso 3: comprobar de nuevo tus claves pública y privada

Un par de claves que no coincide es una de las causas más comunes de un fallo silencioso de handshake, sobre todo si copias claves manualmente entre una configuración de cliente y una de servidor en lugar de usar la app de un proveedor. Confirma que la PrivateKey del cliente corresponde a la clave pública que el servidor tiene registrada para ti, y que la clave pública del servidor en tu configuración de cliente coincide con lo que el servidor realmente presenta. Un solo espacio de más, un carácter que falta o una clave truncada por accidente al copiar y pegar basta para romper el handshake sin ningún otro síntoma.

Paso 4: verificar la dirección y el puerto del endpoint

La línea Endpoint de tu configuración necesita la dirección IP (o el nombre de host) actual y correcta del servidor, además del puerto. Si un proveedor ha rotado recientemente las IP de sus servidores, una configuración antigua en caché que apunte a una dirección ya inexistente fallará en silencio en lugar de mostrar un error claro de DNS o de conexión. Descargar de nuevo un archivo de configuración fresco desde tu proveedor, en lugar de reutilizar uno antiguo guardado, resuelve esto en la mayoría de los casos.

Paso 5: añadir PersistentKeepalive si estás detrás de NAT

Si tu dispositivo está detrás del NAT de un router doméstico, o peor, del CGNAT de un operador móvil (NAT a nivel de operador, habitual en conexiones de datos móviles), el servidor puede perder la capacidad de contactarte de vuelta tras el intento de handshake inicial, ya que la asignación NAT de esa conexión puede caducar por inactividad. Añadir PersistentKeepalive = 25 en la sección de peer de tu configuración de cliente le indica a WireGuard que envíe un pequeño paquete de mantenimiento cada 25 segundos, manteniendo abierta la asignación NAT para que el servidor pueda seguir contactándote. Esta única línea resuelve buena parte de los casos de “se conecta y luego se cae” y de fallos intermitentes de handshake específicamente en redes móviles.

Paso 6: revisar tu ajuste de AllowedIPs

El campo AllowedIPs controla qué tráfico se enruta a través del túnel, y un valor mal configurado aquí puede crear un bucle de enrutamiento que impida que los propios paquetes del handshake lleguen a la interfaz correcta. Si estás resolviendo un problema y no afinando el split tunneling, configurar temporalmente AllowedIPs = 0.0.0.0/0 (todo el tráfico a través del túnel) descarta una mala configuración de enrutamiento como causa, y podrás volver a ajustarlo una vez que la conexión básica funcione.

Paso 7: bajar la MTU si el handshake funciona pero el tráfico no fluye

Si wg show reporta un handshake reciente y exitoso pero sigues sin poder cargar nada, una MTU (unidad máxima de transmisión) demasiado alta que causa fragmentación de paquetes es un culpable habitual, especialmente en conexiones con sobrecarga adicional como datos móviles o ciertas configuraciones de proveedores de internet. Prueba a bajar la MTU de tu configuración a 1280 o 1380 (frente a los 1420 por defecto de WireGuard) y vuelve a conectar. Este síntoma concreto, un handshake exitoso sin flujo real de datos, es una de las señales más claras que apuntan a la MTU en lugar de al propio proceso de handshake.

Paso 8: reiniciar limpiamente en vez de reconectar sobre una sesión atascada

A veces la solución de verdad es apagarlo y volver a encenderlo, pero hacerlo bien importa. Baja completamente la interfaz (sudo wg-quick down wg0) antes de volver a levantarla, en lugar de intentar reconectar sobre una sesión que WireGuard todavía cree activa. Un estado de interfaz atascado a nivel del kernel, especialmente después de que un portátil despierte de suspensión, es una causa común y poco vistosa que un reinicio limpio resuelve sin necesitar ninguna de las comprobaciones más profundas anteriores.

Cuando es un problema del proveedor, no tuyo

Si nada de lo anterior lo resuelve, y sobre todo si la misma configuración funcionaba bien ayer, comprueba si el servidor concreto al que te conectas tiene una caída o una ventana de mantenimiento. Cambiar a otra ubicación de servidor a través de la app de tu proveedor es un paso de diagnóstico más rápido que seguir depurando una configuración que puede ser correcta pero apunta a un servidor simplemente caído. La mayoría de los grandes proveedores publican páginas de estado de servidores o canales de soporte donde este tipo de caída se reconoce rápido. Es una comprobación de cinco minutos que ahorra mucho tiempo perdido dudando de un archivo de configuración que en realidad nunca fue el problema.

Una lista rápida para la próxima vez

Ten en mente este orden aproximado si vuelve a pasar: confirma que la interfaz está activa, descarta un puerto UDP bloqueado probando en otra red, verifica que las claves y la dirección del endpoint están actualizadas, añade PersistentKeepalive si usas datos móviles, y revisa AllowedIPs y la MTU solo si los pasos anteriores no lo resuelven. Recorrer las causas más o menos en este orden, las más comunes y rápidas de comprobar primero, te lleva a una solución más rápido que ponerte a adivinar las posibilidades más raras antes de descartar las sencillas.

Sigue leyendo: WireGuard contra OpenVPN: ¿cuál es mejor? y Cómo instalar un servidor VPN WireGuard en Ubuntu Linux.