VyOS 1.5: MultiWAN con Balanceo de Carga y Failover

Sep 28, 2026 · 15 min read · vyos router wan balanceo failover nat firewall linux

Tener dos proveedores de internet solo sirve si el router sabe usarlos. VyOS resuelve esto con el módulo WAN Load Balancing (load-balancing wan), que reparte las conexiones nuevas entre varios enlaces, vigila la salud de cada uno y los saca de rotación cuando fallan — todo desde el mismo árbol de configuración, sin scripts externos ni marcas de mangle a mano como en otras plataformas.

Este post construye la configuración completa sobre VyOS 1.5 (Circinus), paso a paso, explicando qué hace cada bloque y por qué está ahí.

Escenario de referencia

1ISP1 ─── eth0 (100 Mbps) ┐
2                          ├─── VyOS ─── eth2 ─── LAN (192.168.10.0/24)
3ISP2 ─── eth1 (100 Mbps) ┘

Variable	ISP1	ISP2	LAN
Interfaz	`eth0`	`eth1`	`eth2`
IP del router	`203.0.113.2/30`	`198.51.100.2/30`	`192.168.10.1/24`
Gateway	`203.0.113.1`	`198.51.100.1`	—
Host de monitoreo	`1.1.1.1`	`9.9.9.9`	—

Ajusta las direcciones a tu entorno. Al final hay una sección con los cambios necesarios si uno o ambos ISPs te entregan la IP por DHCP.

Cómo funciona el balanceo en VyOS

Antes de configurar conviene entender el mecanismo, porque explica varias decisiones posteriores:

Cada conexión nueva que entra por la LAN se evalúa contra las reglas de load-balancing wan, en orden numérico.
La regla que coincide elige una WAN según los pesos de las interfaces que estén sanas en ese momento.
La conexión queda marcada en conntrack; todos sus paquetes siguientes salen por la misma WAN. El balanceo es por conexión, no por paquete, así que una descarga individual nunca suma el ancho de banda de ambos enlaces — lo que se reparte es el conjunto de conexiones.
Un proceso de health check prueba cada WAN periódicamente. Si una falla, deja de recibir conexiones nuevas hasta que se recupere.
Por defecto, el módulo aplica source NAT (masquerade) automáticamente con la IP de la WAN elegida.

1. Interfaces

Entra al modo de configuración:

1configure

Asigna direcciones y descripciones:

1set interfaces ethernet eth0 description 'WAN1-ISP1'
2set interfaces ethernet eth0 address '203.0.113.2/30'
3
4set interfaces ethernet eth1 description 'WAN2-ISP2'
5set interfaces ethernet eth1 address '198.51.100.2/30'
6
7set interfaces ethernet eth2 description 'LAN'
8set interfaces ethernet eth2 address '192.168.10.1/24'

1commit

Antes de seguir, comprueba que cada gateway responde desde su propia interfaz:

1run ping 203.0.113.1 interface eth0 count 3
2run ping 198.51.100.1 interface eth1 count 3

Si alguno no responde, no tiene sentido continuar: el balanceador necesita que ambos enlaces funcionen a nivel de capa 3.

2. Rutas estáticas

Necesitamos dos tipos de rutas.

Ruta default en la tabla principal

El balanceador crea sus propias tablas de enrutamiento para el tráfico que viene de la LAN, pero el tráfico originado por el propio router (DNS del router, NTP, actualizaciones, ping desde la CLI) usa la tabla principal. Le damos una default por cada ISP con distancias distintas:

1set protocols static route 0.0.0.0/0 next-hop 203.0.113.1 distance '1'
2set protocols static route 0.0.0.0/0 next-hop 198.51.100.1 distance '10'

Con esto el router sale por ISP1 y usa ISP2 si la interfaz eth0 pierde enlace. Más adelante (paso 8) veremos cómo hacer que también reaccione a caídas upstream.

Rutas de host para los monitores

Cada WAN se vigilará haciendo ping a un host externo distinto. Fijamos una ruta /32 para que cada host de monitoreo siempre se alcance por su enlace correspondiente:

1set protocols static route 1.1.1.1/32 next-hop 203.0.113.1
2set protocols static route 9.9.9.9/32 next-hop 198.51.100.1

Por qué esto importa: sin estas rutas, el ping de monitoreo de WAN2 podría resolverse por la tabla principal y salir por WAN1. Resultado: si ISP2 cae aguas arriba, el health check seguiría respondiendo y el enlace nunca se marcaría como caído. La ruta de host garantiza que la prueba mide el enlace correcto.

El costo es que 1.1.1.1 y 9.9.9.9 quedan atados a un solo ISP. Por eso conviene usar como monitores IPs que no uses para otra cosa (no las pongas como DNS de la LAN), o bien una IP estable dentro de la red de cada ISP.

1commit

3. Health checks de cada WAN

Aquí se define cómo decide VyOS si un enlace está vivo:

 1# WAN1
 2set load-balancing wan interface-health eth0 nexthop '203.0.113.1'
 3set load-balancing wan interface-health eth0 failure-count '3'
 4set load-balancing wan interface-health eth0 success-count '2'
 5set load-balancing wan interface-health eth0 test 10 type 'ping'
 6set load-balancing wan interface-health eth0 test 10 target '1.1.1.1'
 7set load-balancing wan interface-health eth0 test 10 resp-time '3'
 8
 9# WAN2
10set load-balancing wan interface-health eth1 nexthop '198.51.100.1'
11set load-balancing wan interface-health eth1 failure-count '3'
12set load-balancing wan interface-health eth1 success-count '2'
13set load-balancing wan interface-health eth1 test 10 type 'ping'
14set load-balancing wan interface-health eth1 test 10 target '9.9.9.9'
15set load-balancing wan interface-health eth1 test 10 resp-time '3'

Parámetro	Significado
`nexthop`	Gateway del ISP. El balanceador lo usa para construir la tabla de ruteo propia de esa WAN. Es obligatorio.
`failure-count`	Pruebas fallidas consecutivas para marcar el enlace como caído.
`success-count`	Pruebas exitosas consecutivas para devolverlo a rotación.
`test N type`	`ping`, `ttl` (prueba estilo traceroute con TTL limitado) o `user-defined` (script propio).
`target`	Host al que se prueba.
`resp-time`	Segundos máximos de espera por respuesta.

Por qué no probar solo el gateway: el gateway del ISP suele ser el equipo que tienes enfrente (su CPE o su BRAS). Puede responder perfectamente mientras el ISP no tiene salida a internet. Probar un host externo detecta caídas aguas arriba.

Ajuste de sensibilidad: failure-count 3 con success-count 2 es un balance razonable. Valores más bajos reaccionan más rápido pero provocan flapping ante pérdida de paquetes puntual; valores más altos toleran enlaces ruidosos pero tardan más en hacer failover.

4. Reglas de exclusión

Antes de balancear, sacamos del juego el tráfico que no debe ir a internet. Si no lo haces, el tráfico entre tu LAN y otras redes privadas (VLANs, VPN, oficinas remotas) puede terminar marcado y enviado a una WAN.

 1set load-balancing wan rule 5 description 'No balancear trafico privado'
 2set load-balancing wan rule 5 inbound-interface 'eth2'
 3set load-balancing wan rule 5 exclude
 4set load-balancing wan rule 5 destination address '192.168.0.0/16'
 5
 6set load-balancing wan rule 6 description 'No balancear trafico privado'
 7set load-balancing wan rule 6 inbound-interface 'eth2'
 8set load-balancing wan rule 6 exclude
 9set load-balancing wan rule 6 destination address '10.0.0.0/8'
10
11set load-balancing wan rule 7 description 'No balancear trafico privado'
12set load-balancing wan rule 7 inbound-interface 'eth2'
13set load-balancing wan rule 7 exclude
14set load-balancing wan rule 7 destination address '172.16.0.0/12'

El tráfico excluido se enruta normalmente con la tabla principal. Las reglas se evalúan en orden numérico y la primera que coincide gana, así que las exclusiones deben llevar números menores que la regla de balanceo.

5. Regla de balanceo

La regla principal: todo lo que entra por la LAN se reparte entre ambas WAN.

1set load-balancing wan rule 100 description 'Balanceo LAN'
2set load-balancing wan rule 100 inbound-interface 'eth2'
3set load-balancing wan rule 100 protocol 'all'
4set load-balancing wan rule 100 interface eth0 weight '1'
5set load-balancing wan rule 100 interface eth1 weight '1'

Con pesos iguales, cada WAN recibe aproximadamente el 50% de las conexiones nuevas. Si una WAN cae, la regla sigue funcionando con la interfaz que queda: el failover ya está incluido en el balanceo, no hace falta configurarlo aparte.

Enlaces de capacidad distinta

Si ISP1 es de 300 Mbps e ISP2 de 100 Mbps, reparte en proporción 3:1:

1set load-balancing wan rule 100 interface eth0 weight '3'
2set load-balancing wan rule 100 interface eth1 weight '1'

Los pesos son relativos: ISP1 recibe 3 de cada 4 conexiones nuevas.

6. Opciones globales

1set load-balancing wan sticky-connections inbound
2set load-balancing wan flush-connections

sticky-connections inbound: una conexión que entra por una WAN (por ejemplo, un port forward hacia un servidor de la LAN) responde por esa misma WAN. Sin esto, la respuesta podría salir por la otra, con una IP de origen distinta, y el cliente remoto la descartaría.
flush-connections: cuando una WAN cambia de estado, VyOS limpia la tabla de conntrack. Las conexiones atadas al enlace caído se reestablecen de inmediato por el enlace sano en lugar de quedar colgadas hasta su timeout. El costo es que las conexiones del enlace sano también se reinician en ese momento; si eso te molesta más que las sesiones colgadas, omite esta opción.

Source NAT

El balanceador aplica masquerade automáticamente por la interfaz de salida elegida, así que no necesitas reglas NAT adicionales para este escenario. Si prefieres controlar NAT tú mismo (por ejemplo, para usar un pool de IPs públicas en lugar de la IP de la interfaz), desactívalo y define las reglas explícitamente:

1set load-balancing wan disable-source-nat
2
3set nat source rule 100 outbound-interface name 'eth0'
4set nat source rule 100 source address '192.168.10.0/24'
5set nat source rule 100 translation address 'masquerade'
6
7set nat source rule 110 outbound-interface name 'eth1'
8set nat source rule 110 source address '192.168.10.0/24'
9set nat source rule 110 translation address 'masquerade'

Aplica y guarda:

1commit
2save

7. Tráfico fijo a un enlace (con respaldo)

Algunos servicios se rompen si la IP pública de origen cambia entre conexiones: VPNs site-to-site, sesiones de banca en línea, paneles que validan IP de origen, VoIP con registro SIP. Para ellos, en lugar de balancear, usamos una regla failover: siempre sale por el enlace de mayor peso y solo usa el otro si el primero cae.

 1# WireGuard saliente: siempre por ISP1, respaldo ISP2
 2set load-balancing wan rule 20 description 'WireGuard fijo a WAN1'
 3set load-balancing wan rule 20 inbound-interface 'eth2'
 4set load-balancing wan rule 20 protocol 'udp'
 5set load-balancing wan rule 20 destination port '51820'
 6set load-balancing wan rule 20 failover
 7set load-balancing wan rule 20 interface eth0 weight '10'
 8set load-balancing wan rule 20 interface eth1 weight '1'
 9
10# Un host de la LAN (servidor VoIP) siempre por ISP2, respaldo ISP1
11set load-balancing wan rule 30 description 'PBX fijo a WAN2'
12set load-balancing wan rule 30 inbound-interface 'eth2'
13set load-balancing wan rule 30 source address '192.168.10.50'
14set load-balancing wan rule 30 failover
15set load-balancing wan rule 30 interface eth0 weight '1'
16set load-balancing wan rule 30 interface eth1 weight '10'

En modo failover, el peso no reparte tráfico: define prioridad. La interfaz sana con mayor peso es la que se usa.

Observa la numeración final de las reglas:

Regla	Tipo	Qué hace
5–7	exclude	Tráfico privado → tabla principal
20	failover	WireGuard → WAN1 (respaldo WAN2)
30	failover	PBX → WAN2 (respaldo WAN1)
100	balanceo	Todo lo demás → 50/50

Las reglas específicas siempre antes que la general.

1commit
2save

8. Hook: reaccionar a cambios de estado

El balanceador puede ejecutar un script cada vez que una WAN cambia de estado. Lo usaremos para dos cosas: dejar registro en el log y mover la ruta default de la tabla principal (la que usa el propio router, paso 2), que por sí sola solo reacciona a caídas de enlace físico.

Crea el script:

 1sudo tee /config/scripts/wlb-hook.sh > /dev/null << 'EOF'
 2#!/bin/vbash
 3# Variables que entrega VyOS:
 4#   WLB_INTERFACE_NAME   -> eth0, eth1...
 5#   WLB_INTERFACE_STATE  -> ACTIVE | FAILED
 6
 7source /opt/vyatta/etc/functions/script-template
 8
 9logger -t wlb-hook "WAN ${WLB_INTERFACE_NAME} ahora esta ${WLB_INTERFACE_STATE}"
10
11if [ "${WLB_INTERFACE_NAME}" = "eth0" ]; then
12    configure
13    if [ "${WLB_INTERFACE_STATE}" = "FAILED" ]; then
14        set protocols static route 0.0.0.0/0 next-hop 203.0.113.1 distance '250'
15    else
16        set protocols static route 0.0.0.0/0 next-hop 203.0.113.1 distance '1'
17    fi
18    commit
19    exit
20fi
21EOF
22sudo chmod +x /config/scripts/wlb-hook.sh

Regístralo en la configuración:

1set load-balancing wan hook '/config/scripts/wlb-hook.sh'
2commit
3save

Cuando ISP1 falla, su ruta default sube a distancia 250 y la de ISP2 (distancia 10) toma el control para el tráfico del propio router. Cuando ISP1 regresa, se restaura.

/config/scripts/ sobrevive a las actualizaciones de imagen de VyOS. No guardes scripts en otro lugar.

9. Firewall

El balanceo no reemplaza al firewall. Una base mínima con la sintaxis de VyOS 1.5 que protege al router en ambas WAN:

 1# Estado de conexiones, global
 2set firewall global-options state-policy established action 'accept'
 3set firewall global-options state-policy related action 'accept'
 4set firewall global-options state-policy invalid action 'drop'
 5
 6# Tráfico hacia el router
 7set firewall ipv4 input filter default-action 'drop'
 8set firewall ipv4 input filter rule 10 description 'LAN al router'
 9set firewall ipv4 input filter rule 10 action 'accept'
10set firewall ipv4 input filter rule 10 inbound-interface name 'eth2'
11set firewall ipv4 input filter rule 20 description 'ICMP desde WAN'
12set firewall ipv4 input filter rule 20 action 'accept'
13set firewall ipv4 input filter rule 20 protocol 'icmp'
14set firewall ipv4 input filter rule 30 action 'accept'
15set firewall ipv4 input filter rule 30 inbound-interface name 'lo'
16
17# Tráfico a través del router
18set firewall ipv4 forward filter default-action 'drop'
19set firewall ipv4 forward filter rule 10 description 'LAN a internet'
20set firewall ipv4 forward filter rule 10 action 'accept'
21set firewall ipv4 forward filter rule 10 inbound-interface name 'eth2'

Los pings de monitoreo son tráfico saliente del router (cadena output, aceptada por defecto) y sus respuestas entran como established, así que no necesitan regla adicional.

1commit
2save

10. Verificación

Sal del modo configuración (exit) para los comandos operacionales.

Estado de cada WAN:

1show wan-load-balance

Salida esperada con ambos enlaces sanos:

 1Interface:  eth0
 2  Status:  active
 3  Last Status Change:  Mon Sep 28 10:12:44 2026
 4  +Test:  ping  Target: 1.1.1.1
 5    Last Interface Success:  0s
 6    Last Interface Failure:  n/a
 7    # Interface Failure(s):  0
 8
 9Interface:  eth1
10  Status:  active
11  ...

Conexiones y la WAN asignada a cada una:

1show wan-load-balance connection

Tráfico por interfaz en tiempo real:

1monitor bandwidth interface eth0
2monitor bandwidth interface eth1

Distribución desde un cliente de la LAN: abre varias conexiones a un servicio que devuelva tu IP pública. Con balanceo 50/50 debes ver alternarse ambas IPs:

1for i in $(seq 1 10); do curl -s https://ifconfig.me; echo; done

Algunos clientes reutilizan la conexión HTTP (keep-alive) y siempre verán la misma IP. curl en un bucle abre conexiones nuevas cada vez.

Simular la caída de una WAN

La prueba más fiel es desconectar el cable de ISP1, pero para simular una caída aguas arriba (gateway vivo, internet muerta) bloquea el host de monitoreo:

1configure
2set firewall ipv4 output filter rule 999 action 'drop'
3set firewall ipv4 output filter rule 999 destination address '1.1.1.1'
4commit

En unos segundos (failure-count × intervalo de prueba) show wan-load-balance debe mostrar eth0 como failed, el log registrará el evento del hook y todo el tráfico nuevo saldrá por eth1:

1show log | match wlb-hook

Restaura:

1delete firewall ipv4 output filter rule 999
2commit
3exit

Si tus ISPs entregan IP por DHCP

Solo cambian tres cosas:

1set interfaces ethernet eth0 address dhcp
2set interfaces ethernet eth0 dhcp-options default-route-distance '1'
3
4set interfaces ethernet eth1 address dhcp
5set interfaces ethernet eth1 dhcp-options default-route-distance '10'
6
7set load-balancing wan interface-health eth0 nexthop 'dhcp'
8set load-balancing wan interface-health eth1 nexthop 'dhcp'

Elimina las rutas default estáticas del paso 2: DHCP las instala con las distancias indicadas.
nexthop dhcp hace que el balanceador tome el gateway que entregue el ISP en cada renovación.
Las rutas /32 de los monitores necesitan un gateway fijo. Con DHCP, usa set protocols static route 1.1.1.1/32 dhcp-interface 'eth0' (y lo mismo con 9.9.9.9 por eth1).
En el hook, sustituye el cambio de distancia de ruta estática por set interfaces ethernet eth0 dhcp-options default-route-distance '250' y su reverso.

Configuración completa

 1set interfaces ethernet eth0 address '203.0.113.2/30'
 2set interfaces ethernet eth0 description 'WAN1-ISP1'
 3set interfaces ethernet eth1 address '198.51.100.2/30'
 4set interfaces ethernet eth1 description 'WAN2-ISP2'
 5set interfaces ethernet eth2 address '192.168.10.1/24'
 6set interfaces ethernet eth2 description 'LAN'
 7
 8set protocols static route 0.0.0.0/0 next-hop 203.0.113.1 distance '1'
 9set protocols static route 0.0.0.0/0 next-hop 198.51.100.1 distance '10'
10set protocols static route 1.1.1.1/32 next-hop 203.0.113.1
11set protocols static route 9.9.9.9/32 next-hop 198.51.100.1
12
13set load-balancing wan flush-connections
14set load-balancing wan hook '/config/scripts/wlb-hook.sh'
15set load-balancing wan sticky-connections inbound
16
17set load-balancing wan interface-health eth0 failure-count '3'
18set load-balancing wan interface-health eth0 nexthop '203.0.113.1'
19set load-balancing wan interface-health eth0 success-count '2'
20set load-balancing wan interface-health eth0 test 10 resp-time '3'
21set load-balancing wan interface-health eth0 test 10 target '1.1.1.1'
22set load-balancing wan interface-health eth0 test 10 type 'ping'
23set load-balancing wan interface-health eth1 failure-count '3'
24set load-balancing wan interface-health eth1 nexthop '198.51.100.1'
25set load-balancing wan interface-health eth1 success-count '2'
26set load-balancing wan interface-health eth1 test 10 resp-time '3'
27set load-balancing wan interface-health eth1 test 10 target '9.9.9.9'
28set load-balancing wan interface-health eth1 test 10 type 'ping'
29
30set load-balancing wan rule 5 destination address '192.168.0.0/16'
31set load-balancing wan rule 5 exclude
32set load-balancing wan rule 5 inbound-interface 'eth2'
33set load-balancing wan rule 6 destination address '10.0.0.0/8'
34set load-balancing wan rule 6 exclude
35set load-balancing wan rule 6 inbound-interface 'eth2'
36set load-balancing wan rule 7 destination address '172.16.0.0/12'
37set load-balancing wan rule 7 exclude
38set load-balancing wan rule 7 inbound-interface 'eth2'
39
40set load-balancing wan rule 20 destination port '51820'
41set load-balancing wan rule 20 failover
42set load-balancing wan rule 20 inbound-interface 'eth2'
43set load-balancing wan rule 20 interface eth0 weight '10'
44set load-balancing wan rule 20 interface eth1 weight '1'
45set load-balancing wan rule 20 protocol 'udp'
46
47set load-balancing wan rule 30 failover
48set load-balancing wan rule 30 inbound-interface 'eth2'
49set load-balancing wan rule 30 interface eth0 weight '1'
50set load-balancing wan rule 30 interface eth1 weight '10'
51set load-balancing wan rule 30 source address '192.168.10.50'
52
53set load-balancing wan rule 100 inbound-interface 'eth2'
54set load-balancing wan rule 100 interface eth0 weight '1'
55set load-balancing wan rule 100 interface eth1 weight '1'
56set load-balancing wan rule 100 protocol 'all'

Consideraciones de producción

El balanceo es por conexión. Un speedtest de un solo flujo nunca mostrará la suma de ambos enlaces. Los speedtests multi-hilo sí pueden acercarse, porque abren varias conexiones que caen en WANs distintas.

Sitios que rompen con IPs cambiantes. Algunos servicios web asocian la sesión a la IP de origen; si la página abre conexiones nuevas que salen por otra WAN, la sesión se invalida. Si detectas uno, fíjalo con una regla failover por destination address como en el paso 7.

Servicios publicados hacia internet. El balanceo gobierna el tráfico saliente. Para servicios entrantes, sticky-connections inbound asegura que las respuestas salgan por la WAN correcta, pero el failover de cara al exterior depende de DNS: publica el servicio con TTL bajo y usa un proveedor con health checks que cambie el registro si una IP deja de responder.

IPv6. El módulo load-balancing wan trabaja sobre IPv4. Con IPv6 lo habitual es no balancear: cada ISP delega su prefijo, y la LAN anuncia ambos o solo el del enlace activo según tu estrategia de failover.

Monitores robustos. Un solo host de prueba por WAN es un punto único de falla: si 1.1.1.1 tiene un mal día, sacarás de rotación un enlace sano. En entornos críticos, usa como target una IP dentro de la red del propio ISP (su DNS, por ejemplo), que valida el enlace sin depender de terceros.