Comparativa de rendimiento: Port Forwarding vs WireGuard VPN

En la gestión de infraestructura de red surge con frecuencia la necesidad de interconectar dos puntos geográficos para que los usuarios de una sede remota consuman servicios alojados en la oficina principal. En mi experiencia administrando los sistemas de DOSCLIC, me enfrenté al reto de conectar la Sede B con la Sede A, donde conviven un sistema web institucional sobre IIS, sistemas DVR de videovigilancia y relojes biométricos de control de asistencia.

1. El escenario inicial y el problema del puerto 8000

En el Punto A disponía de un enlace dedicado de fibra óptica (proveedor empresarial, contratado a 500 Mbps) con una dirección IP pública estática. Las pruebas de velocidad en la consola local sobre Windows 10 LTSC mostraron una latencia base de 14.17 ms, con una bajada de 215.71 Mbps y subida de 179.81 Mbps. La administración central de la red está a cargo de un router MikroTik RB3011UiAS (código de firmware 7.12.1, arquitectura ARM dual-core a 1400 MHz con 1 GB de RAM).

Inicialmente, el sistema principal en VB.NET / ASP.NET alojado en la IP local 192.168.10.2:80 se consumía desde el exterior aplicando una regla de Destination NAT (Port Forwarding) en el MikroTik hacia la IP pública. Todo funcionaba de forma transparente para los usuarios finales. Sin embargo, al requerir que el software de gestión administrara el reloj biométrico ubicado en la IP 192.168.10.5:8000, repliqué el mapeo de puerto en el router. La conexión falló rotundamente.

2. Diagnóstico técnico: ¿Por qué falló el Port Forwarding?

A diferencia de una aplicación web tradicional bajo HTTP/TCP que tolera NAT sin contratiempos, los dispositivos IoT y biométricos (fabricantes como ZKTeco, Anviz o Suprema) utilizan arquitecturas de red con características particulares que rompen al exponerse tras NAT:

En primer lugar, muchos SDKs y programas de gestión realizan peticiones de descubrimiento por difusión local (broadcast en 255.255.255.255 o 192.168.10.255), paquetes que los routers no reenvían a través de reglas NAT a Internet. En segundo lugar, algunos de estos dispositivos incrustan su IP privada interna dentro del payload de las respuestas TCP/UDP. Cuando el cliente remoto en el Punto B recibe la respuesta, el paquete le indica intentar conectarse a la IP interna 192.168.10.5, resultando inalcanzable desde fuera. Finalmente, existe software que valida de forma estricta estar en el mismo segmento de subred o que utiliza canales UDP separados para el intercambio de datos que el NAT no rastrea correctamente.

3. La solución con WireGuard VPN

Para solventar la contingencia, configuré una interfaz WireGuard (wg0) en el router MikroTik del Punto A. Al levantar el túnel capa 3 de sitio a sitio entre ambos puntos, la estación cliente en el Punto B pasó a formar parte del plano de direccionamiento privado.

Al procesar los paquetes dentro del túnel, el tráfico del reloj biométrico viaja empaquetado de forma transparente. Para el software de gestión, el dispositivo se encuentra dentro de la misma LAN, solucionando de inmediato los fallos de asignación de puertos y validación de subred.

/interface wireguard add name=wg0 listen-port=13231
/ip address add address=10.99.0.1/24 interface=wg0

Un factor crucial en la estabilidad del túnel fue el ajuste del valor MTU en la interfaz de WireGuard a 1420 bytes. Este margen evita la fragmentación de paquetes IP al contemplar el overhead del encabezado UDP/IP de la encapsulación.

4. Comparativa de rendimiento y arquitectura

Al evaluar objetivamente ambas soluciones en términos de números y comportamiento operativo, se obtienen los siguientes hallazgos:

En cuanto a la latencia, el Port Forwarding registra un overhead mínimo (~0.3 ms a 1 ms) derivado de las tablas de conntrack y reglas de firewall. Por su parte, WireGuard suma entre 1 ms y 4 ms de latencia adicional por el cifrado simétrico mediante el algoritmo ChaCha20-Poly1305. No obstante, en un enlace real de 200 a 500 Mbps con una latencia de transporte de ~14 ms, esa penalización es prácticamente imperceptible para el usuario y no representa ningún cuello de botella.

Respecto al procesamiento en el router MikroTik RB3011UiAS, la CPU ARM dual-core a 1.4 GHz soporta entre 300 y 600 Mbps de rendimiento real bajo WireGuard, superando holgadamente la capacidad contratada de la línea.

Configuración de túnel: Full Tunnel vs Split Tunnel

Al definir la directiva AllowedIPs en el cliente WireGuard se controlan dos modos de operación distintos:

Si se configura AllowedIPs = 0.0.0.0/0 (Full Tunnel), todo el tráfico de Internet del cliente se canaliza a través de la sede central. Esto resulta sumamente útil cuando la Sede B requiere salir hacia Internet con la misma dirección IP pública estática del Punto A para consumir servicios institucionales restringidos por lista blanca de IP (como repositorios universitarios o portales gubernamentales).

/ip firewall nat add chain=srcnat out-interface=ether1 action=masquerade

Si únicamente se requiere acceso a los recursos internos de la empresa sin recargar el ancho de banda del Punto A, se aplica Split Tunnel especificando solo los bloques requeridos: AllowedIPs = 10.99.0.0/24, 192.168.10.0/24.

5. Despliegue con OpenWRT

Esta arquitectura puede extenderse hacia equipos secundarios o entornos domésticos utilizando routers con firmware OpenWRT (como equipos Netgear de 256 MB de RAM y procesador dual-core). La instalación del servicio se realiza directamente mediante la gestión de paquetes nativa:

opkg update && opkg install wireguard-tools luci-app-wireguard

Implementar OpenWRT junto con WireGuard permite convertir cualquier router en un gateway privado de bajo costo, eliminando la necesidad de publicar puertos al exterior y cerrando por completo la exposición de servicios sensibles hacia Internet.