FortiGate Dual WAN: cómo diseñar failover con SD-WAN y Performance SLA
Tener dos proveedores de internet no significa automáticamente tener una conexión a internet altamente disponible.
Una empresa puede contratar:
- ISP 1 por fibra
- ISP 2 por fibra, cable, radio o 5G
y aun así experimentar interrupciones aunque los dos enlaces aparezcan físicamente como activos.
El problema es que un enlace puede seguir teniendo señal y mantener su interfaz UP mientras presenta:
- Pérdida de paquetes
- Latencia excesiva
- Jitter
- Problemas de routing del proveedor
- Fallas parciales hacia Internet
- Degradación hacia aplicaciones específicas
Por eso un diseño empresarial de FortiGate Dual WAN debería ir más allá de detectar si el cable está conectado.
Con FortiGate SD-WAN y Performance SLA podemos medir la calidad de cada enlace y tomar decisiones de routing basadas en el comportamiento real de la conexión.
En esta guía de la Biblioteca Virtual Sistro 2.0 explicamos cómo diseñar correctamente dos ISP, qué diferencia existe entre failover tradicional y SD-WAN, qué debemos medir y qué errores pueden provocar que la redundancia no funcione cuando realmente la necesitamos.
Consulta Firewalls Fortinet FortiGate disponibles en Sistro
¿Qué significa Dual WAN?
Dual WAN significa disponer de dos conexiones WAN que pueden utilizarse por el firewall.
Por ejemplo:
ISP 1 → FortiGate WAN1
ISP 2 → FortiGate WAN2
Pero existen diferentes formas de utilizar esas conexiones.
Podemos tener:
- Enlace primario y enlace de respaldo
- Load balancing
- Routing por aplicación
- Routing según calidad
- SD-WAN
- Diferentes combinaciones de las anteriores
La arquitectura correcta depende de las aplicaciones y de la criticidad del negocio.
Failover tradicional: ISP 1 falla y utilizamos ISP 2
El modelo más sencillo sería:
ISP 1 = Primario
ISP 2 = Backup
Mientras ISP 1 está disponible, todo el tráfico utiliza ese enlace.
Cuando falla, FortiGate envía el tráfico por ISP 2.
Este modelo puede ser adecuado para determinadas redes.
Pero aparece una pregunta importante:
¿qué significa exactamente que un enlace haya fallado?
Una interfaz UP no significa que Internet funcione
Supongamos que el módem del proveedor continúa conectado al FortiGate.
La interfaz Ethernet permanece activa.
Desde el punto de vista físico:
WAN1 = UP
Pero el proveedor tiene un problema en su backbone.
El resultado puede ser:
- No existe navegación
- Existe pérdida importante
- Microsoft 365 responde mal
- La VPN tiene problemas
- Teams se escucha entrecortado
Si solamente observamos el estado físico de la interfaz, el firewall podría seguir creyendo que el enlace está disponible.
Aquí entra Performance SLA
FortiGate SD-WAN permite utilizar Performance SLA para evaluar la salud de los enlaces.
El firewall puede realizar pruebas hacia destinos definidos y medir variables como:
- Latencia
- Jitter
- Pérdida de paquetes
En lugar de preguntar únicamente:
“¿La interfaz está conectada?”
podemos preguntar:
“¿La calidad de este enlace es suficientemente buena para esta aplicación?”
¿Qué es latencia?
La latencia representa el tiempo que tarda el tráfico en viajar entre dos puntos.
Generalmente la medimos en milisegundos.
Una latencia elevada puede afectar especialmente:
- VoIP
- Videoconferencia
- Aplicaciones interactivas
- Escritorios remotos
- Aplicaciones empresariales sensibles
Una descarga de archivos puede tolerar cierta latencia.
Una llamada de voz probablemente sea mucho más sensible.
¿Qué es jitter?
Jitter representa la variación de latencia entre paquetes.
Podemos tener un enlace donde:
Paquete 1 tarda 20 ms
Paquete 2 tarda 90 ms
Paquete 3 tarda 25 ms
Paquete 4 tarda 110 ms
El promedio puede parecer aceptable.
Pero la experiencia de voz o video puede ser muy mala.
Por eso jitter es particularmente importante para aplicaciones en tiempo real.
¿Qué es packet loss?
Packet loss representa el porcentaje de paquetes que no llegan correctamente a su destino.
Un enlace puede seguir funcionando con cierta pérdida.
Pero conforme aumenta podemos experimentar:
- Retransmisiones
- Navegación lenta
- Audio entrecortado
- Video inestable
- VPN degradada
- Aplicaciones que pierden sesiones
Por eso una conexión puede estar técnicamente activa pero ser prácticamente inutilizable.
Performance SLA permite medir las tres variables
Una política SD-WAN puede evaluar simultáneamente:
Latency + Jitter + Packet Loss
y tomar decisiones cuando el enlace deja de cumplir los niveles definidos.
Los valores correctos dependen de la aplicación.
No deberíamos utilizar exactamente los mismos límites para:
- Teams
- ERP
- Backup
- Navegación
- VoIP
- Replicación
No existe un SLA universal
Este es uno de los puntos más importantes.
No recomiendo copiar valores de latencia, jitter y pérdida de otro proyecto sin entender el servicio.
Un SLA debe definirse según:
- Aplicación
- Proveedor
- Ubicación
- Tipo de enlace
- Distancia
- Requerimientos del negocio
¿Cómo verifica FortiGate la salud del enlace?
FortiGate puede utilizar health checks activos o mediciones basadas en tráfico real, dependiendo del diseño y versión de FortiOS.
Una prueba activa puede enviar tráfico hacia un destino conocido.
Por ejemplo:
WAN1 → servidor de prueba
WAN2 → servidor de prueba
Después FortiGate analiza la calidad de cada camino.
No utilices un solo destino sin pensarlo
Supongamos que utilizamos únicamente un servidor para determinar si Internet funciona.
El servidor deja de responder.
Los dos enlaces están perfectamente sanos.
Pero nuestro health check puede interpretar que existe un problema.
Por eso el diseño del destino de prueba es importante.
FortiGate permite utilizar más de un servidor en determinados health checks para reducir este tipo de falsos positivos.
¿Qué deberíamos probar?
Depende del objetivo.
Si queremos comprobar Internet general podemos utilizar destinos altamente disponibles.
Si queremos medir una aplicación específica, puede tener más sentido comprobar infraestructura asociada con esa aplicación.
Por ejemplo:
- Microsoft 365
- AWS
- Data center corporativo
- Aplicación SaaS
- Hub VPN
El health check debe representar aquello que realmente necesitamos proteger.
Failover no es lo mismo que SD-WAN
Un failover básico responde:
“¿Cuál enlace utilizo si el principal falla?”
SD-WAN puede responder preguntas adicionales:
“¿Cuál enlace funciona mejor para esta aplicación?”
“¿Cuál cumple actualmente el SLA?”
“¿Por qué enlace debería salir Teams?”
“¿Por cuál debería salir el backup?”
Consulta también nuestra guía FortiGate con SD-WAN
Ejemplo: dos proveedores con diferente calidad
Supongamos:
ISP 1
1 Gbps
Latencia baja
Enlace principal
ISP 2
500 Mbps
Latencia un poco mayor
Enlace de respaldo
Podemos utilizar ISP 1 normalmente.
Pero si comienza a presentar pérdida de paquetes que afecta Teams, podemos enviar temporalmente esa aplicación por ISP 2 aunque WAN1 siga físicamente activa.
Eso es mucho más inteligente que esperar una caída total.
SD-WAN por aplicación
Las reglas SD-WAN pueden utilizar criterios para seleccionar diferentes enlaces.
Podemos diseñar políticas para:
Microsoft 365
Preferir el enlace con mejor comportamiento hacia servicios cloud.
VoIP
Priorizar baja latencia, bajo jitter y poca pérdida.
Backup
Utilizar un enlace con mayor capacidad cuando la latencia no sea tan crítica.
Navegación general
Balancear o utilizar la estrategia que corresponda.
ERP
Priorizar el enlace que mantiene mejor comunicación hacia el data center o cloud donde reside la aplicación.
VoIP es un excelente ejemplo
Una llamada no consume enormes cantidades de ancho de banda.
Pero necesita calidad.
Podemos tener:
ISP 1 → 1 Gbps pero jitter alto
ISP 2 → 300 Mbps pero conexión estable
Para una llamada, ISP 2 puede proporcionar mejor experiencia aunque tenga menos ancho de banda.
Por eso:
más Mbps no siempre significa mejor enlace.
Teams y videoconferencia
Algo similar ocurre con aplicaciones de colaboración.
Teams, Zoom, Webex y otras plataformas necesitan estabilidad.
Una pequeña cantidad de packet loss puede ser más perceptible que una reducción moderada de ancho de banda.
SD-WAN puede utilizar métricas de calidad para tomar decisiones más útiles.
Load balancing tampoco es igual a SD-WAN
Otro error común consiste en utilizar ambos enlaces simplemente repartiendo tráfico.
Eso puede aprovechar capacidad.
Pero no necesariamente toma en cuenta la experiencia de las aplicaciones.
Un balanceo podría enviar una sesión crítica por un enlace degradado simplemente porque todavía está activo.
SD-WAN agrega contexto sobre la calidad.
¿Puedo utilizar ambos ISP al mismo tiempo?
Sí.
Dependiendo del diseño podemos utilizar los dos enlaces activamente.
Por ejemplo:
ISP 1 → aplicaciones críticas
ISP 2 → navegación y backups
y mantener capacidad de failover entre ambos.
Otra opción es balancear determinadas cargas.
La decisión debe basarse en los objetivos de la empresa.
Fiber + Broadband
No es obligatorio que los dos enlaces sean idénticos.
Podemos utilizar:
Fibra empresarial + Internet comercial
La fibra puede actuar como enlace principal y el segundo proveedor como contingencia.
Esta combinación puede proporcionar una buena relación entre disponibilidad y costo.
Fiber + 5G
Otra arquitectura cada vez más útil para sucursales es:
Fibra + LTE/5G
El enlace celular puede mantenerse como respaldo para:
- ERP
- POS
- VPN
- Aplicaciones críticas
mientras limitamos tráfico de menor prioridad cuando funciona sobre la contingencia.
El enlace de respaldo no necesariamente debe soportar todo
Este punto puede reducir costos.
Supongamos que una oficina normalmente utiliza 800 Mbps.
No siempre necesitamos comprar dos circuitos de 1 Gbps.
Durante contingencia podemos priorizar:
- ERP
- Microsoft 365
- VoIP
- VPN
- POS
y restringir:
- Actualizaciones
- Backups
- Streaming
- Tráfico no esencial
Así el enlace secundario puede ser más pequeño pero mantener la operación crítica.
¿Qué ocurre cuando vuelve ISP 1?
El failback también debe diseñarse.
No queremos que el tráfico cambie constantemente entre WAN1 y WAN2 porque el proveedor está entrando y saliendo marginalmente del SLA.
Esto puede generar:
- Flapping
- Reinicio de sesiones
- Experiencia inestable
- Problemas de VPN
Por eso deben definirse correctamente los parámetros para declarar un enlace caído y los parámetros para considerarlo recuperado.
No seas demasiado agresivo con el failover
Una sola respuesta ICMP perdida no necesariamente significa que debamos abandonar inmediatamente un ISP.
Internet tiene variaciones naturales.
Debemos utilizar umbrales que eviten reaccionar a eventos aislados pero detecten problemas reales con suficiente rapidez.
El failover puede romper sesiones existentes
Cuando cambiamos de ISP normalmente también cambia la dirección IP pública utilizada por la conexión.
Algunas sesiones existentes pueden necesitar restablecerse.
Esto puede afectar:
- Aplicaciones web
- VPN
- Telefonía
- Conexiones persistentes
- Servicios publicados
Por eso no debemos vender Dual WAN como:
“cero interrupciones ante cualquier falla”.
El objetivo es reducir el impacto y automatizar la recuperación.
Dual WAN para navegación es más sencillo que Dual WAN para servicios publicados
Para usuarios que salen hacia Internet, el firewall puede cambiar de enlace y crear nuevas sesiones.
Pero si tenemos un servidor publicado hacia Internet existe otro problema:
¿cómo sabrán los usuarios externos que deben conectarse ahora a la otra dirección pública?
Esto puede requerir diseños adicionales como:
- DNS
- Balanceadores
- BGP
- Servicios cloud
- Arquitecturas específicas de publicación
Dos WAN no resuelven automáticamente la alta disponibilidad de servicios entrantes.
Dual WAN y VPN site-to-site
En empresas distribuidas podemos crear diferentes caminos VPN entre sucursales.
Por ejemplo:
Sucursal ISP1 → Corporativo
Sucursal ISP2 → Corporativo
y utilizar SD-WAN para seleccionar el overlay adecuado.
Esto puede aumentar considerablemente la resiliencia de una red empresarial.
Dual WAN no reemplaza FortiGate HA
Supongamos que tenemos:
ISP 1 + ISP 2
pero ambos llegan a:
un solo FortiGate.
Tenemos redundancia de proveedor.
Pero seguimos teniendo un punto único de falla:
el firewall.
Si la operación es crítica debemos evaluar también alta disponibilidad.
Consulta nuestra guía FortiGate High Availability
Arquitectura con mayor disponibilidad
Una arquitectura empresarial puede evolucionar hacia:
ISP 1 + ISP 2
↓
FortiGate A + FortiGate B en HA
↓
Switching redundante
↓
LAN / WiFi / Servidores
Ahora estamos trabajando diferentes capas de resiliencia.
El switch también puede ser un punto único de falla
Dos proveedores y dos firewalls no sirven de mucho si toda la infraestructura depende de un único switch crítico.
La disponibilidad debe revisarse de extremo a extremo.
Debemos analizar:
- ISP
- Firewalls
- Switches
- Energía
- UPS
- Routing
- DNS
- Aplicaciones
Performance SLA activo
Una medición activa envía probes periódicos para evaluar el enlace.
Tiene la ventaja de producir información incluso cuando no existe tráfico real de usuarios.
Esto permite conocer continuamente el estado del enlace.
Medición pasiva
FortiOS también dispone de mecanismos que pueden utilizar tráfico real para evaluar la salud de determinados enlaces.
Esto puede proporcionar información basada en la experiencia real de las sesiones.
La elección depende de la arquitectura y de la versión de FortiOS.
¿Qué es Prefer Passive?
En determinadas versiones de FortiOS existe un enfoque donde el firewall puede preferir métricas obtenidas mediante tráfico real y utilizar probes activos cuando no existe suficiente tráfico para realizar la medición.
Esto combina ambos enfoques.
No midas solamente el ISP
Otro concepto importante:
Una conexión puede tener excelente acceso hacia un servidor de prueba y mala ruta hacia una aplicación crítica.
Por eso podemos diseñar SLA asociados con servicios específicos.
Por ejemplo:
SLA Internet
SLA Microsoft 365
SLA Data Center
SLA VoIP
Cada uno puede representar un objetivo diferente.
FortiGuard SLA Database
En versiones recientes de FortiOS, Fortinet también dispone de una base de datos FortiGuard con destinos SaaS e Internet que pueden utilizarse para determinadas configuraciones de Performance SLA cuando se dispone del entitlement correspondiente.
Esto puede simplificar la selección de destinos para servicios conocidos.
Escenario 1: oficina con dos fibras
Supongamos:
- ISP 1 de 1 Gbps
- ISP 2 de 500 Mbps
- 80 empleados
- Microsoft 365
- Telefonía IP
- VPN
Podemos utilizar ISP 1 como preferido y mantener ISP 2 disponible.
Si ISP 1 empieza a degradarse, las aplicaciones sensibles pueden cambiar de camino antes de una caída completa.
Escenario 2: sucursal con fibra + 5G
Tenemos:
- Fibra de 300 Mbps
- 5G de respaldo
- POS
- ERP cloud
- VoIP
Durante una contingencia podemos permitir solamente las aplicaciones críticas sobre 5G.
Así reducimos consumo y mantenemos operación.
Escenario 3: empresa con veinte sucursales
Tenemos una sede principal y veinte oficinas remotas.
Cada sucursal puede tener dos proveedores.
FortiGate SD-WAN puede seleccionar rutas según:
- Aplicación
- Calidad
- Costo
- Disponibilidad
y utilizar diferentes VPN hacia el corporativo.
Consulta nuestra guía Fortinet para sucursales empresariales
Escenario 4: ISP rápido pero inestable
Supongamos:
ISP 1 → 1 Gbps pero pérdida intermitente
ISP 2 → 500 Mbps estable
Un simple esquema basado en ancho de banda preferiría siempre ISP 1.
Una estrategia SD-WAN puede seleccionar ISP 2 para determinados servicios cuando la calidad de WAN1 deja de cumplir el SLA.
Escenario 5: dos ISP pero un solo FortiGate
El cliente considera que ya tiene alta disponibilidad.
Pero una falla de hardware del FortiGate detendría ambos enlaces.
Aquí debemos separar:
redundancia WAN
de
redundancia del firewall.
¿Qué modelo FortiGate necesito?
Dual WAN y SD-WAN existen en diferentes modelos FortiGate.
La selección debe hacerse de acuerdo con:
- Velocidad total de WAN
- Usuarios
- Dispositivos
- VPN
- IPS
- Threat Protection
- SSL Inspection
- Sesiones
- Sucursales
- Crecimiento
Consulta nuestra comparativa FortiGate 70G vs 90G vs 120G
Internet total tampoco debe confundirse con capacidad NGFW
Supongamos:
ISP 1 = 1 Gbps
ISP 2 = 1 Gbps
No debemos concluir automáticamente:
“Necesito exactamente 2 Gbps de firewall throughput”.
Debemos revisar qué tráfico puede ser simultáneo y qué perfiles de seguridad se aplicarán.
Las métricas relevantes pueden incluir:
- NGFW Throughput
- Threat Protection
- SSL Inspection
- IPsec VPN
- Sesiones
Errores comunes al configurar FortiGate Dual WAN
1. Revisar solamente si la interfaz está UP
El proveedor puede estar degradado aunque Ethernet continúe activo.
2. Utilizar un único destino poco confiable
Puede producir falsos positivos.
3. Configurar los mismos SLA para todas las aplicaciones
VoIP y backup tienen requerimientos diferentes.
4. Hacer failover demasiado rápido
Podemos provocar flapping.
5. Hacer failback demasiado rápido
Un enlace inestable puede generar cambios constantes.
6. Confundir load balancing con SD-WAN
Repartir tráfico no significa medir experiencia.
7. Pensar que dos WAN eliminan todos los puntos únicos de falla
El FortiGate y los switches también importan.
8. No considerar sesiones existentes
Algunas conexiones tendrán que restablecerse al cambiar de ISP.
9. Olvidar las VPN
Debemos diseñar caminos alternativos también para conectividad entre sedes.
10. No probar una falla real
Una arquitectura Dual WAN debe probarse desconectando o degradando un enlace de manera controlada.
Checklist antes de implementar Dual WAN
Antes de diseñar deberíamos conocer:
- Modelo FortiGate
- Versión FortiOS
- ISP 1
- ISP 2
- Tipo de acceso
- Ancho de banda de cada enlace
- Direcciones públicas
- Aplicaciones críticas
- VoIP
- Videoconferencia
- VPN site-to-site
- VPN de usuarios
- Servicios publicados
- Microsoft 365
- SaaS
- ERP
- Requerimientos de latencia
- Requerimientos de jitter
- Packet loss tolerable
- Política de failover
- Política de failback
- Necesidad de HA
- Switching
- UPS
Preguntas que Sistro debería hacer antes de configurar SD-WAN
- ¿Cuántos proveedores tienes?
- ¿Qué velocidad ofrece cada uno?
- ¿Cuál debería ser el principal?
- ¿Qué aplicaciones no pueden detenerse?
- ¿Utilizas VoIP?
- ¿Utilizas Teams o videoconferencia?
- ¿Tienes sucursales?
- ¿Cuántas VPN existen?
- ¿Publicas servicios hacia Internet?
- ¿El enlace secundario debe soportar toda la operación?
- ¿Cuánto tiempo puedes tolerar una interrupción?
- ¿También necesitas FortiGate HA?
Después podemos diseñar las reglas y Performance SLA.
Pruebas que deberíamos realizar antes de considerar terminado el proyecto
Una implementación Dual WAN no debería entregarse sin pruebas.
Recomendaríamos validar:
- Desconectar físicamente ISP 1
- Restaurar ISP 1
- Desconectar ISP 2
- Simular pérdida de paquetes
- Simular latencia
- Comprobar llamadas
- Comprobar VPN
- Comprobar aplicaciones críticas
- Comprobar failback
- Validar logs y Performance SLA
El objetivo es comprobar que el comportamiento real corresponde con el diseño.
FortiGate Dual WAN dentro de Biblioteca Virtual Sistro 2.0
Este artículo complementa directamente nuestras guías anteriores.
FortiGate con SD-WAN: cuándo conviene
Fortinet para sucursales empresariales
Productos Fortinet en Sistro
Firewalls Fortinet FortiGate
https://sistro.net/firewalls-fortinet
FortiGate 70G
https://sistro.net/firewalls-fortinet/FortiGate-70G
FortiGate 120G
https://sistro.net/fortigate-120g-firewall-corporativo
Recomendación final
Tener dos conexiones de internet es solamente el primer paso hacia una red más disponible.
El verdadero valor aparece cuando el firewall puede determinar:
qué enlace funciona, qué tan bien funciona y para qué aplicación funciona mejor.
FortiGate SD-WAN y Performance SLA permiten evolucionar desde un failover básico hacia una estrategia donde medimos:
Latencia + Jitter + Packet Loss + Aplicación + Disponibilidad.
Pero la implementación debe diseñarse con cuidado.
Un health check incorrecto puede provocar falsos failovers.
Un failback demasiado agresivo puede generar inestabilidad.
Y dos ISP no eliminan el riesgo si seguimos teniendo un solo firewall, un solo switch o una sola fuente de energía.
La pregunta correcta no es:
“¿Tengo dos proveedores?”
Es:
“¿Qué ocurre con mis aplicaciones cuando uno de ellos empieza a fallar?”
¿Quieres implementar Dual WAN o SD-WAN con FortiGate?
En Sistro Networks podemos ayudarte a revisar enlaces, aplicaciones, VPN, latencia, jitter, pérdida de paquetes, rutas y nivel de disponibilidad requerido.
Diseñamos los Performance SLA y reglas SD-WAN de acuerdo con la operación de la empresa, no solamente con el ancho de banda contratado.
Consulta soluciones Fortinet FortiGate en Sistro Networks
Preguntas frecuentes
¿FortiGate soporta dos proveedores de internet?
Sí. FortiGate puede integrar múltiples interfaces WAN y utilizar SD-WAN para aplicar distintas estrategias de selección y failover.
¿Qué es Performance SLA?
Es una función de SD-WAN que permite medir la salud y calidad de los enlaces mediante variables como latencia, jitter y pérdida de paquetes.
¿FortiGate puede cambiar de ISP aunque el enlace siga activo?
Sí. Dependiendo de las reglas y SLA configurados, un enlace puede dejar de utilizarse para determinadas aplicaciones cuando su calidad ya no cumple los objetivos definidos.
¿Dual WAN es lo mismo que SD-WAN?
No. Dual WAN describe la disponibilidad de varios enlaces. SD-WAN agrega inteligencia para seleccionar rutas según reglas, aplicaciones y calidad.
¿Load balancing es lo mismo que SD-WAN?
No. Load balancing distribuye tráfico. SD-WAN puede incorporar además estado del enlace, calidad y objetivos específicos de aplicación.
¿Necesito dos enlaces de la misma velocidad?
No. Pueden utilizarse enlaces de diferente capacidad y tecnología siempre que el diseño contemple qué tráfico debe utilizar cada uno.
¿Puedo usar 5G como respaldo?
Sí. Dependiendo de la infraestructura disponible, un enlace celular puede utilizarse como contingencia para aplicaciones prioritarias.
¿Dual WAN reemplaza FortiGate HA?
No. Dos WAN proporcionan redundancia de conectividad. FortiGate HA proporciona redundancia del firewall. Son capas diferentes.
¿El failover mantiene todas las sesiones?
No necesariamente. Al cambiar de proveedor puede cambiar la dirección IP pública y algunas sesiones pueden necesitar establecerse nuevamente.
¿Performance SLA puede medir jitter?
Sí. Fortinet utiliza latencia, jitter y pérdida de paquetes como métricas de calidad para Performance SLA.
Deja un Comentario