Configuración de WireGuard Site-to-Site y acceso a servicios internos

Al implementar una topología VPN site-to-site con WireGuard utilizando un router doméstico con firmware DD-WRT como pasarela, es común encontrarse con la ilusión de una conexión establecida: los peers responden al comando ping entre sí, pero el tráfico hacia las máquinas y servicios de la red local interna simplemente se desvanece en el vacío.

1. El escenario y el síntoma inicial

El objetivo consistía en interconectar un puesto remoto con Windows 10 (IP de túnel 10.10.0.4) con la red local de una oficina técnica (192.168.52.0/24), situada detrás de un router Netgear R7000 con DD-WRT v3.0 (IP de túnel 10.10.0.5 y LAN 192.168.52.1), todo enlazado a través de un VPS central con WireGuard (10.10.0.1).

En el segmento interno, un servidor local en 192.168.52.113 alojaba un servicio IIS escuchando en el puerto 8012. Al realizar las pruebas iniciales desde PowerShell en el cliente remoto, el resultado fue negativo:

Test-NetConnection 192.168.52.113 -Port 8012
WARNING: TCP connect to (192.168.52.113 : 8012) failed
WARNING: Ping to 192.168.52.113 failed with status: TimedOut

ComputerName           : 192.168.52.113
RemoteAddress          : 192.168.52.113
RemotePort             : 8012
InterfaceAlias         : ucm_vpn_client
SourceAddress          : 10.10.0.4
PingSucceeded          : False
TcpTestSucceeded       : False

Sin embargo, el ping directo hacia el peer del router (10.10.0.5) respondía sin pérdida de paquetes. Esto confirmó que el túnel L3 estaba operativo y con handshakes activos, pero el tráfico no transitaba hacia el switch/bridge local de la LAN.

2. Diagnóstico del filtrado en DD-WRT

Para que un router actúe como pasarela transitiva en una VPN site-to-site se requieren tres condiciones fundamentales:

• Reenvío IP activo a nivel de kernel (ip_forward = 1).
• Rutas anunciadas en las AllowedIPs de WireGuard en ambos extremos (incluyendo la subred 192.168.52.0/24).
• Reglas en la tabla filter de Netfilter/iptables que permitan el paso bidireccional entre la interfaz VPN (oet1 en DD-WRT) y el bridge de la LAN (br0).

Al auditar el router mediante SSH se comprobó el reenvío IP:

sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

Al inspeccionar las reglas activas con iptables -S y en el archivo temporal autogenerado /tmp/.ipt, se descubrió la raíz del bloqueo: DD-WRT construye cadenas auxiliares como SECURITY, lan2wan, trigger_out y tarpit. Aunque la política por defecto en FORWARD figuraba como ACCEPT, el tráfico no relacionado era derivado hacia trampas de filtrado antes de cruzar hacia br0.

3. El conflicto de SSH y la cadena INPUT

Al inyectar reglas de prueba generales para el reenvío, el acceso al puerto 8012 de la LAN comenzó a responder, pero surgió un efecto colateral imprevisto: se cortó la administración SSH directa al router (10.10.0.5:22).

ssh -vvv root@10.10.0.5
OpenSSH_for_Windows_9.5p2, LibreSSL 3.8.2
debug1: Connecting to 10.10.0.5 [10.10.0.5] port 22.
debug1: Connection established.
...
debug1: Local version string SSH-2.0-OpenSSH_for_Windows_9.5
kex_exchange_identification: Connection closed by remote host
Connection closed by 10.10.0.5 port 22

El establecimiento inicial TCP ocurría, pero la negociación del intercambio de claves (kex_exchange_identification) era terminada abruptamente. Esto sucede porque el tráfico hacia el propio router es evaluado por la cadena INPUT y no por FORWARD. La cadena SECURITY contenía filtros que bloqueaban selectivamente paquetes de control provenientes de interfaces virtuales.

4. Configuración definitiva y persistencia

En DD-WRT, ejecutar comandos en terminal solo altera la memoria RAM; tras un reinicio, el sistema reconstruye /tmp/.ipt y borra las reglas manuales. Para lograr estabilidad permanente sin degradar la seguridad del firewall base, se deben registrar reglas atómicas y de alta prioridad desde la interfaz gráfica.

El conjunto mínimo y limpio de reglas que resuelve el reenvío LAN y el acceso administrativo SSH es el siguiente:

# Permitir reenvio bidireccional entre la VPN (oet1) y la LAN fisica (br0)
iptables -I FORWARD 1 -i oet1 -o br0 -d 192.168.52.0/24 -j ACCEPT
iptables -I FORWARD 2 -i br0 -o oet1 -s 192.168.52.0/24 -j ACCEPT

# Permitir administracion SSH hacia el router desde la interfaz VPN
iptables -I INPUT 1 -i oet1 -p tcp --dport 22 -j ACCEPT

Tras guardar y reiniciar el equipo, las comprobaciones de conectividad hacia el servicio web IIS y hacia el demonio SSH fueron exitosas de forma simultánea y persistente.

5. Límites del enrutamiento L3: Protocolos de descubrimiento y Jump Hosts

Una vez consolidado el túnel hacia la red interna, surgió la necesidad de gestionar dispositivos multimedia (Smart TVs, Google TV y asistentes domóticos) a través de la VPN. Al intentar vincular las aplicaciones móviles, los dispositivos no aparecían en las búsquedas automáticas.

¿Por qué falla el descubrimiento automático?

WireGuard opera en la Capa 3 (Red / IP) mediante enrutamiento unicast. Los ecosistemas como Google Cast, Apple AirPlay o SSDP/UPnP dependen estrictamente de tráfico broadcast y multicast (como mDNS en 224.0.0.251 puerto 5353) dentro del mismo dominio de Capa 2 (Enlace de datos / Ethernet).

Estrategias evaluadas:

• Túnel L2 (Bridge Ethernet con OpenVPN TAP o GRETAP): Permite extender broadcast y multicast, pero introduce sobrecarga de ancho de banda, mayor latencia, fragmentación de paquetes y complejidad innecesaria en DD-WRT.
• Reflector mDNS (avahi-daemon): Requiere soporte para retransmitir multicast entre interfaces, no siempre disponible o estable en builds embebidos de routers.
• Nodo de salto / Host de administración local (Solución recomendada): Mantener WireGuard en Capa 3 pura y desplegar un dispositivo de bajo consumo dentro de la LAN (un mini PC, Thin Client o Raspberry Pi ejecutando Home Assistant o Linux con VNC/RDP). Al residir físicamente en 192.168.52.0/24, este nodo procesa el descubrimiento multicast local y expone interfaces de control gestionables a través del túnel seguro.