Dos WAN y una sola IP autorizada: Policy Routing en Omada paso a paso
Por qué una conexión entre sedes por IP pública «a veces anda y a veces no» cuando el router tiene dos WAN con balanceo, cómo diagnosticarlo y cómo resolverlo en Omada con un grupo de IP y una regla de Policy Routing. Con IPs de ejemplo.
Un caso que me tocó hace poco en una planta industrial: los empleados de administración usan un sistema de gestión cuyo servidor está en otra sede, en otra ciudad. No hay VPN entre los dos lados: la conexión va directo por Internet, de IP pública a IP pública, y del otro lado el firewall solo deja pasar a la IP de la planta.
El reclamo era el clásico: "a veces anda y a veces no". Sin mensajes de error claros, sin horario fijo, sin un patrón. Los dos lados tienen el mismo proveedor de Internet, así que nadie entendía qué podía fallar.
La causa estaba en el router de la planta: tenía dos WAN con balanceo de carga. En esta entrada va el caso completo, con IPs de ejemplo, y cómo se resuelve en Omada con una regla de Policy Routing.
Las capturas son de la instalación real, un router Omada ER8411 manejado por un controlador OC200 con Omada 6.3. Reemplacé los nombres y las IPs por los del ejemplo.
El escenario, con IPs de ejemplo
Las IPs son de ejemplo (rangos reservados para documentación), pero la estructura es la del caso real:
SEDE A: planta (red 192.168.3.0/24)
Router Omada con dos WAN y balanceo 50/50
┌─────────────────────────────────────────┐
│ WAN/LAN4 ── IP pública 203.0.113.10 │ ← la autorizada
PCs de ────────┤ │
administración │ WAN/LAN5 ── módem 192.168.50.2 │
│ sale como 198.51.100.77 │ ← NO autorizada
└────────────────────┬────────────────────┘
│ Internet (mismo proveedor)
▼
SEDE B: servidor del sistema de gestión
IP pública 192.0.2.31, SQL Server en el puerto 1433
Firewall: solo acepta conexiones desde 203.0.113.10| Dónde | Qué | IP |
|---|---|---|
| Sede A | WAN/LAN4 (proveedor, IP fija) | 203.0.113.10 |
| Sede A | WAN/LAN5 (detrás del módem, con NAT) | 192.168.50.2 → sale como 198.51.100.77 |
| Sede A | Red de las PCs | 192.168.3.0/24 |
| Sede B | Servidor del sistema (SQL Server, puerto 1433) | 192.0.2.31 |
| Sede B | IP de origen permitida en su firewall | solo 203.0.113.10 |
En el router, las bocas WAN/LAN se pueden usar como WAN o como LAN. En este caso, la 4 y la 5 están como WAN, y en el dashboard del controlador se ven las dos:
Por qué "a veces anda"
El balanceo de carga de un router con varias WAN no reparte paquetes, reparte conexiones. Cada conexión nueva sale por una WAN u otra según los pesos configurados (acá, 50/50). Una vez que una conexión arrancó por una WAN, se queda ahí hasta que termina.
Desde el lado de la sede B, lo que se ve es esto:
- Si la conexión del sistema salió por WAN/LAN4, llega desde
203.0.113.10: el firewall la deja pasar y anda. - Si salió por WAN/LAN5, llega desde
198.51.100.77: el firewall la descarta y no anda. El programa espera, da timeout o tira un error genérico de conexión.
Más o menos la mitad de las veces anda y la otra mitad no, según por dónde le tocó salir. Y como cada intento nuevo es una conexión nueva, "cerrá y volvé a abrir el programa" a veces lo arregla, lo que confunde todavía más.
Que los dos lados tengan el mismo proveedor no cambia nada: la conexión igual va de IP pública a IP pública, y lo que el otro lado mira es la IP de origen.
Cómo diagnosticarlo
1. Ver con qué IP pública sale la red
Desde una PC de la sede A, consultar la IP pública varias veces seguidas. En Linux:
for i in $(seq 1 10); do curl -s https://api.ipify.org; echo; sleep 2; doneEn Windows (PowerShell):
1..10 | ForEach-Object { (Invoke-RestMethod https://api.ipify.org); Start-Sleep 2 }Si aparecen dos IPs distintas, ya está: la red sale por más de una WAN. Ojo, que el balanceo puede ser "pegajoso" por un rato y mostrar siempre la misma. En mi caso, la primera consulta dio 198.51.100.77 y las siguientes 24 dieron 203.0.113.10. Conviene repetirlo en otro momento.
2. Probar el puerto del servidor
Para descartar que el servidor esté caído, hay que probar si el puerto responde. En Linux:
timeout 3 bash -c "</dev/tcp/192.0.2.31/1433" && echo "1433 abierto"En Windows:
Test-NetConnection 192.0.2.31 -Port 1433Esta prueba hay que hacerla desde la red que sí está autorizada. Si el firewall de la sede B filtra por IP de origen, desde otro lado el puerto va a aparecer cerrado aunque el servidor ande perfecto.
3. Mirar la configuración de las WAN en el controlador
Todo lo que sigue está en el menú Network Config del sitio. Al hacer clic se despliega con todas las secciones. Las que usamos son Network Settings → Internet, Transmission → Routing y Profile → Groups:
En Network Config → Internet, en Port Config, se ven las bocas que están como WAN (con Set to WAN Port activado). Más abajo, en Load Balancing, están los pesos de cada una:
En el caso real estaba así:
- WAN/LAN4 y WAN/LAN5 activas, con Load Balancing Weight de 10 y 10 (50/50).
- Application Optimized Routing activado: intenta que las conexiones de una misma aplicación salgan por la misma WAN, pero no garantiza cuál.
- Link Backup apagado: no hay WAN principal y de respaldo, las dos trabajan a la par.
- Ninguna regla de Policy Routing.
Con eso se confirma el diagnóstico.
La solución: Policy Routing
Policy Routing es una regla que le dice al router: "el tráfico que va a tal destino sale siempre por tal WAN". El resto del tráfico sigue balanceándose como siempre: la regla afecta solo a lo que coincide con ella.
En Omada se hace en dos pasos: primero un grupo de IP con el destino, y después la regla.
Paso 1: crear el grupo de IP del destino
En Network Config → Profile → Groups está la lista de grupos. Los que terminan en _Any vienen de fábrica. Con Create New Group se crea uno nuevo:
| Campo | Valor |
|---|---|
| Name | Sistema-SedeB |
| Type | IP Group |
| IP Subnet | 192.0.2.31 / 32 |
| Description | Servidor del sistema de gestión (opcional) |
La máscara /32 significa "esta IP sola". Si la sede B tuviera varios servidores, se suman con Add Subnet en el mismo grupo.
Paso 2: crear la regla de Policy Routing
En Network Config → Transmission → Routing, pestaña Policy Routing → Create New Routing:
| Campo | Valor | Por qué |
|---|---|---|
| Name | Sistema SedeB por WAN4 |
Que se entienda solo |
| Status | Enable | |
| Protocols | All | No importa el puerto: todo lo que vaya a ese servidor |
| WAN | WAN/LAN4 (la de 203.0.113.10) |
Es la IP que el otro lado tiene autorizada |
| Use the other WAN port if the current one is down | Enable | Si WAN/LAN4 se cae, el resto no se corta en el router (igual el sistema no va a andar, porque WAN/LAN5 no está autorizada) |
| Source → Type | Network | |
| Source | Las redes que usan el sistema (o todas) | |
| Destination → Type | IP Group | |
| Destination | Sistema-SedeB |
El grupo del paso 1 |
El origen y el destino se eligen abajo, en Routing Legend, que además dibuja la regla: de las redes marcadas, por WAN/LAN4, al grupo de destino.
Guardar, y el controlador manda la configuración al router en unos segundos. La regla queda en la lista:
Si hay varias reglas, se aplican en orden de arriba hacia abajo, y se reordenan arrastrando desde los puntitos de la izquierda.
En versiones 5.x del controlador los menús se llaman distinto: el grupo está en Settings → Profiles → Groups y la regla en Settings → Transmission → Routing → Policy Routing. Si el router está en modo standalone (sin controlador), la regla está en su propia web, en Transmission → Routing → Policy Routing.
Paso 3: verificar
- La regla tiene que aparecer en la lista de Policy Routing, con Enabled activado.
- El router y los equipos tienen que seguir conectados.
- La prueba de fuego es preguntarle a la gente de la sede B desde qué IP les llegan las conexiones. Tiene que ser siempre
203.0.113.10. - Y probar el sistema varias veces seguidas, cerrando y abriendo el programa, desde distintas PCs.
Para volver atrás, alcanza con borrar la regla y el grupo. No toca nada más.
Cosas para tener en cuenta
- Usuarios por VPN. Si hay gente que entra a la red de la sede A por VPN y usa el sistema desde ahí, su tráfico no viene de las redes de la regla. Hay que revisar si hace falta incluirlos.
- La IP del destino tiene que ser fija. Si la IP pública de la sede B es dinámica (por ejemplo, una conexión PPPoE común), cuando cambie se corta todo, con o sin regla. Hay que confirmarlo con el proveedor.
- La alternativa sin tocar el router: que la sede B autorice las dos IPs de la sede A. Funciona, pero solo si WAN/LAN5 también tiene IP fija.
- Lo más prolijo sería no exponer el SQL Server a Internet. Un puerto 1433 abierto en una IP pública es un blanco constante de ataques por fuerza bruta, aunque esté filtrado por IP. Una VPN sitio a sitio entre las dos sedes (IPsec o WireGuard, que los routers Omada manejan) resuelve todo de una: el tráfico va por el túnel, el puerto deja de estar publicado y se termina el problema de las IPs de origen.
En resumen
| Síntoma | Causa | Solución |
|---|---|---|
| Un sistema remoto "a veces anda y a veces no" | El router tiene dos WAN con balanceo y el otro lado autoriza una sola IP de origen | Policy Routing: el tráfico a ese destino sale siempre por la WAN autorizada |
El dato que destraba todo es acordarse de que el balanceo cambia la IP pública de salida. Cada vez que algo depende de "desde qué IP llego" (un firewall con lista blanca, un home banking empresarial, una API con IP autorizada, un acceso a AFIP/ARCA desde servidor), en una red con varias WAN hace falta una regla de Policy Routing.
Si querés armar un router Omada desde cero, está la entrada de configuración inicial del ER605, y para el controlador, la de Controlador Omada en Docker.
