Cómo solucionar problemas del servidor VPN en X-WRT

 Le preguntamos a Gemini, la inteligencia artificial de Google, cómo solucionar problemas del servidor VPN en X-WRT 

Explicanos detalladamente cómo solucionar problemas del servidor VPN en X-WRT

Al estar basado en la pila de OpenWrt, X-WRT administra la red y los servicios mediante el sistema unificado de configuración uci, el motor de cortafuegos (firewall4 con nftables o firewall3 con iptables) y la interfaz web LuCI.

Los fallos en un servidor VPN sobre X-WRT (ya sea WireGuard, OpenVPN o L2TP/IPsec) se concentran habitualmente en 4 capas: Acceso WAN / CGNAT, Reglas de Cortafuegos / NAT, Enrutamiento / Solapamiento de Subredes y Ajustes de MTU/MSS.

A continuación se detalla la metodología sistemática para diagnosticar y resolver estas fallas.

1.1. Inspeccionar los registros del sistema (Logs):

Uso de logread y estado del demonio en la consola.

Accede a la CLI del router por SSH o mediante la terminal integrada en LuCI para capturar los eventos en tiempo real mientras el cliente intenta conectar:

Bash

# Ver eventos específicos de WireGuard

logread -f | grep -i wireguard

# Ver eventos específicos de OpenVPN

logread -f | grep -i openvpn

# Ver estado global de las interfaces de red

ubus call network.interface dump

Si no ves ningún log entrante: El tráfico no está llegando a la interfaz WAN del router (falla de puerto, IP incorrecta o CGNAT).

Si ves conexiones rechazadas: Hay un fallo de llaves/certificados o el firewall está descartando los paquetes (drop).

2.2. Verificar la IP Pública y estado de CGNAT:

Descarte de IP privada de WAN o proveedores con CGNAT.

Si tu proveedor de internet (ISP) te asigna una dirección bajo CGNAT (rango 100.64.0.0/10) o tu router X-WRT está detrás de un módem/ONT en modo Router, las peticiones externas nunca tocarán tu puerto VPN.

Compara la IP asignada a la interfaz WAN con tu IP pública real:Bash# IP asignada a la WAN en el router

uci show network.wan.ipaddr

# IP pública real vista desde internet

curl -s https://ifconfig.me

Solución: Si las IPs no coinciden, debes poner el módem de tu ISP en modo Bridge (Puente) o realizar un Port Forwarding del puerto de la VPN (ej. UDP 51820 para WireGuard o UDP 1194 para OpenVPN) desde el módem hacia la IP WAN del X-WRT.

3.3. Auditar las zonas del Cortafuegos (Firewall / UCI):

Configurar reglas de entrada y reenvío de zonas.

Un error común en X-WRT es crear la interfaz VPN pero no asociarla a una Zona de Firewall ni habilitar el reenvío hacia la zona lan.

Edita la configuración desde la consola (/etc/config/firewall) o mediante LuCI en Red > Cortafuegos:

Permitir tráfico entrante al puerto VPN en WAN:

Plaintext

config rule

       option name 'Allow-VPN-Input'

       option src 'wan'

       option proto 'udp'

       option dest_port '51820' # Ajustar al puerto de tu VPN

       option target 'ACCEPT'

Permitir el reenvío de tráfico entre la zona VPN y la zona LAN (Forwarding):

Plaintext

config forwarding

      option src 'vpn'

      option dest 'lan'



config forwarding

      option src 'lan'

      option dest 'vpn'

Habilitar Masquerading (NAT) en la zona VPN:

En la definición de la zona vpn, asegúrate de incluir option masquerade '1' para que los clientes VPN puedan salir a Internet a través de la conexión del router.

Aplica los cambios en el firewall:

Bash

/etc/init.d/firewall restart

4.4. Comprobar solapamiento de subredes (Subnet Conflicts):

Prevenir colisiones de direccionamiento IP.

Si la subred de la LAN de tu X-WRT es 192.168.1.0/24 y el cliente que se conecta a la VPN está en una red remota que también usa 192.168.1.0/24 (ej. un hotel o casa del cliente), el enrutamiento fallará. El cliente no sabrá si enviar el paquete a su red local o al túnel.

Solución: Cambia el rango LAN local de X-WRT a un segmento menos común (ej. 10.20.30.0/24 o 172.26.0.0/24).

Verifica que la subred propia de la VPN (ej. 10.8.0.0/24) sea completamente independiente de la LAN y WAN.

5.5. Ajustar el MTU y activar MSS Clamping:

Evitar la congelación de tráfico por tamaño de paquete.

Si el cliente establece la conexión VPN exitosamente, pero las páginas web se quedan cargando infinitamente o las transferencias SSH se congelan, el problema es la fragmentación de paquetes (MTU excesivo).

Ajustar el MTU en la interfaz VPN:

En WireGuard o OpenVPN, reduce el MTU a 1420 o 1360 (para compensar el encabezado del túnel).

Bash

# En /etc/config/network para la interfaz wg0

uci set network.wg0.mtu='1420'

uci commit network

/etc/init.d/network restart

Activar MSS Clamping en el Firewall:

Asegúrate de que el ajuste de MSS esté activo en la zona WAN/VPN dentro de /etc/config/firewall:

Plaintext

config zone

       option name 'wan'

        ...

       option mtu_fix '1'

Tabla de Comandos Rápidos de Diagnóstico en X-WRT

Tarea	Comando CLI en X-WRT
Ver estado de WireGuard	wg show
Ver clientes conectados (OpenVPN)	cat /var/log/openvpn-status.log
Verificar tabla de rutas activas	ip route show
Comprobar reglas de NAT activas	nft list ruleset | grep -i masquerade (o iptables -t nat -L -n -v)
Escuchar tráfico en el puerto VPN	tcpdump -n -i eth0 udp port 51820

Matriz de Resolución de Errores Comunes

1. WireGuard: "Handshake did not complete"

Causa: La llave pública del cliente/servidor no coincide, el puerto está bloqueado en el firewall WAN, o el endpoint asignado en el cliente apunta a una IP/DNS desactualizado.

Fix: Ejecuta wg show en X-WRT. Si el latest handshake no se actualiza o está en blanco, revisa la coincidencia exacta de las Public Keys y Preshared Keys, y confirma con tcpdump si llegan paquetes al puerto UDP configurado.

2. Conecta a la VPN pero NO hay acceso a la LAN local ni a Internet

Causa: Falta de la regla de Masquerade en la interfaz VPN/WAN o falta de reenvío (Forwarding) entre zonas.

Fix: Habilita el enrutamiento de IP en el kernel: sysctl -w net.ipv4.ip_forward=1. Asegúrate de que los clientes VPN reciban un servidor DNS accesible (ej. la IP del propio router X-WRT 192.168.X.1 o DNS públicos como 1.1.1.1).

3. El DNS se filtra o no resuelve nombres de la red local

Causa: dnsmasq en X-WRT está rechazando peticiones que provienen de interfaces fuera de la zona LAN habitual.

Fix: En LuCI (Red > DHCP y DNS > General), o en /etc/config/dhcp, asegúrate de desactivar la opción Rechazar consultas no locales (Locally served domains) o añade la interfaz VPN a la lista de escucha de dnsmasq.

¿Quieres optimizar la configuración de WireGuard mediante scripts UCI en X-WRT?