SonicWall High Availability: Active/Standby vs Stateful HA, qué cambia y cuándo conviene
Una empresa puede tener dos proveedores de Internet, switches administrables, UPS y enlaces redundantes.
Pero si toda la conectividad pasa por un solo firewall, todavía existe un punto único de falla.
Supongamos:
ISP 1 + ISP 2 → un solo SonicWall → red empresarial
Tenemos redundancia de Internet.
Pero si ese SonicWall presenta una falla de hardware, se reinicia inesperadamente o necesita mantenimiento, ambos proveedores pueden quedar temporalmente inutilizados para la red.
Para reducir este riesgo SonicWall incorpora mecanismos de High Availability o HA.
Podemos utilizar dos firewalls compatibles como un par:
SonicWall Primario + SonicWall Secundario
y permitir que el segundo tome el control cuando el dispositivo activo deja de operar correctamente.
Pero existen diferencias importantes entre:
- Active/Standby
- Active/Standby Stateless
- Stateful High Availability
- Active/Active DPI
Y esas diferencias determinan qué ocurre realmente con nuestras sesiones cuando existe un failover.
En esta guía de la Biblioteca Virtual Sistro 2.0 explicamos cómo funciona SonicWall High Availability, qué necesitamos para implementarlo y cuándo vale la pena invertir en un segundo firewall.
Consulta Firewalls SonicWall disponibles en Sistro
¿Qué es High Availability en SonicWall?
High Availability permite configurar dos firewalls SonicWall compatibles para proporcionar redundancia.
Normalmente tenemos:
Primary / Active
y
Secondary / Standby
El equipo Active procesa el tráfico.
El equipo Standby monitorea al activo y está preparado para tomar sus responsabilidades cuando se detecta una condición de falla.
Dos firewalls deben ser del mismo modelo
Este punto es fundamental.
Un par SonicWall HA se construye utilizando appliances idénticos.
No debemos intentar formar HA con:
TZ470 + TZ570
o:
NSa 2800 + NSa 3800.
El par debe utilizar el mismo modelo y firmware compatible.
¿Por qué debe ser el mismo hardware?
Porque durante un failover el firewall secundario debe asumir la misma configuración, interfaces y responsabilidades que el primario.
Necesitamos consistencia en:
- Interfaces
- Capacidad
- Firmware
- Configuración
- Servicios
La idea es que la red pueda continuar utilizando una plataforma equivalente.
Active/Standby: la arquitectura básica
Podemos imaginar:
Internet
↓
SonicWall A — Active
SonicWall B — Standby
↓
LAN
Durante operación normal:
SonicWall A procesa el tráfico.
SonicWall B permanece preparado para tomar el control.
¿Qué ocurre cuando falla el firewall activo?
El equipo secundario deja de recibir determinadas señales de salud del activo.
Si se cumplen las condiciones configuradas para failover, el secundario cambia de estado y se convierte en Active.
Entonces empieza a procesar el tráfico de la red.
Pero existe una pregunta crítica
¿Qué ocurre con las conexiones que estaban abiertas antes del failover?
Ahí aparece la diferencia entre HA stateless y Stateful HA.
Active/Standby Stateless
En un esquema Active/Standby sin Stateful Synchronization, la configuración general se mantiene sincronizada entre ambos firewalls.
Pero las sesiones dinámicas activas no necesariamente están disponibles en el secundario.
Cuando ocurre un failover, las conexiones existentes pueden necesitar establecerse nuevamente.
¿Qué significa en la práctica?
Podemos tener usuarios realizando:
- Navegación web
- ERP
- VPN
- VoIP
- Transferencias
- Sesiones RDP
El segundo SonicWall toma el control.
La red recupera conectividad.
Pero determinadas sesiones pueden reiniciarse.
Ejemplo sencillo
Un usuario tiene una sesión HTTPS abierta.
El Primary falla.
El Secondary toma el control.
Si el estado de esa conexión no estaba sincronizado, la sesión anterior puede dejar de ser válida.
El navegador establece una nueva conexión.
Para navegación web esto puede ser apenas perceptible.
Para otras aplicaciones puede resultar más evidente.
Stateful High Availability
Stateful HA agrega sincronización dinámica de estados entre ambos firewalls.
El objetivo es que el equipo Standby conozca información sobre las conexiones que está manejando el Active.
Conceptualmente:
SonicWall Active
↓ sincronización de estado
SonicWall Standby
Cuando ocurre el failover, el secundario dispone de mucha más información para continuar procesando tráfico existente.
¿Qué puede sincronizar Stateful HA?
El objetivo es mantener información dinámica relacionada con elementos como:
- Sesiones activas
- Conexiones
- Determinada información VPN
- Estados necesarios para continuidad
No debemos interpretar esto como que absolutamente todos los estados posibles de todas las aplicaciones son idénticos después de cualquier falla.
Pero proporciona una continuidad considerablemente superior frente a un failover stateless.
Stateful HA no es solamente “otro firewall encendido”
Existe comunicación continua entre los dos dispositivos.
Por eso necesitamos interfaces específicas para HA.
Entre ellas podemos encontrar:
- HA Control Interface
- HA Data Interface
dependiendo de la arquitectura y funciones utilizadas.
HA Control Interface
El enlace de control permite a los appliances intercambiar información necesaria para administrar el par.
Por ejemplo:
- Heartbeats
- Estado del equipo
- Configuración
- Información de HA
HA Data Interface
Cuando utilizamos funciones que requieren mayor intercambio de información, una interfaz de datos dedicada puede utilizarse para sincronizar estados y otra información necesaria.
Separar estas funciones ayuda a mantener una comunicación estable entre los dos dispositivos.
¿Stateful HA requiere licencia?
Dependiendo del modelo y plataforma, Stateful Synchronization puede requerir licenciamiento adicional.
Por eso antes de cotizar un par HA debemos comprobar:
- Modelo exacto
- Generación
- Versión SonicOS
- Licencias disponibles
- Tipo de HA requerido
No debemos asumir que todas las modalidades están incluidas de la misma manera en todos los appliances.
Active/Standby HA sí está incluido en múltiples plataformas SonicWall
SonicWall publica soporte Active/Standby para múltiples familias TZ y NSa.
Pero Stateful HA puede aparecer como una capacidad opcional.
Por eso siempre conviene revisar el SKU y la ficha vigente antes de construir la cotización.
¿Qué es Virtual MAC?
Cuando ocurre un failover también debemos considerar las tablas ARP de switches, routers y otros dispositivos.
SonicWall puede utilizar una dirección MAC virtual compartida entre los integrantes del par.
Esto ayuda a reducir el tiempo necesario para que la red reconozca qué appliance está activo.
Sin Virtual MAC
Un cambio de dispositivo puede requerir que otros equipos actualicen sus tablas ARP.
Durante ese proceso puede existir una pequeña ventana de convergencia.
Con Virtual MAC
Los equipos pueden compartir una identidad MAC virtual para determinados propósitos.
Después del failover el nuevo Active puede anunciar esa identidad mediante gratuitous ARP.
Esto simplifica la convergencia en muchos diseños.
High Availability no debe depender únicamente de saber si el firewall está encendido
Un appliance puede estar energizado pero tener un problema en una interfaz o camino crítico.
Por eso SonicWall permite configurar mecanismos de HA Monitoring.
Physical Interface Monitoring
Podemos monitorear el estado físico de interfaces seleccionadas.
Por ejemplo:
WAN
LAN
Uplink hacia Core
Si una interfaz crítica pierde enlace, podemos utilizar esa condición dentro de la lógica de HA.
Logical Monitoring
El monitoreo lógico va más allá del estado del puerto.
Podemos comprobar conectividad hacia un dispositivo confiable dentro de una red determinada.
Esto permite detectar escenarios como:
Interfaz física UP
pero
red detrás de la interfaz inaccesible.
Ejemplo de Logical Monitoring
Tenemos:
SonicWall → Switch Core → Router / Gateway
El cable entre SonicWall y switch sigue conectado.
Pero existe un problema más adelante.
Un monitor lógico puede ayudarnos a determinar si el camino realmente continúa siendo funcional.
No configures un monitor hacia un destino poco confiable
Un destino mal elegido puede provocar failovers innecesarios.
El elemento monitoreado debe representar de manera razonable la salud de la red que queremos validar.
HA Monitoring y SD-WAN resuelven problemas diferentes
Este punto conecta con nuestro artículo anterior.
SD-WAN puede decidir:
¿qué ISP debería utilizar?
HA puede decidir:
¿qué firewall debería estar procesando la red?
Son capas diferentes.
Consulta SonicWall SD-WAN con Dual WAN y SLA Probes
Dos ISP no sustituyen HA
Esta arquitectura:
ISP 1 + ISP 2 → SonicWall A
protege contra determinadas fallas de Internet.
Pero SonicWall A sigue siendo un punto único de falla.
Dos firewalls no sustituyen Dual WAN
Ahora pensemos:
ISP 1 → SonicWall A/B en HA
Tenemos redundancia de firewall.
Pero ISP 1 continúa siendo un punto único de falla de conectividad.
Una arquitectura más completa
Podemos evolucionar hacia:
ISP 1 + ISP 2
↓
SonicWall A + SonicWall B en HA
↓
Switching redundante
↓
LAN / WiFi / Servidores
Ahora estamos reduciendo múltiples puntos únicos de falla.
Pero todavía debemos revisar los switches
Supongamos que tenemos:
- Dos ISP
- Dos SonicWall
pero ambos firewalls conectan hacia:
un solo switch core.
La falla del switch todavía puede interrumpir toda la operación.
High Availability es una disciplina de extremo a extremo
Debemos revisar:
- ISP
- Firewalls
- Switches
- Uplinks
- Fuentes de alimentación
- UPS
- Storage
- DNS
- Aplicaciones
No basta con comprar dos firewalls.
Stateful HA y VPN
Las VPN pueden ser especialmente sensibles a un failover.
En un esquema stateless es posible que determinados túneles o sesiones necesiten renegociarse.
Stateful Synchronization busca reducir ese impacto manteniendo información dinámica relevante sincronizada.
Esto puede resultar importante para:
- VPN site-to-site
- Usuarios remotos
- Aplicaciones persistentes
- Conexiones críticas
Stateful no significa “matemáticamente cero interrupciones”
No recomiendo vender HA prometiendo que jamás se perderá un paquete o que cualquier aplicación permanecerá exactamente igual ante cualquier falla imaginable.
Existen variables externas:
- Switching
- ARP
- WAN
- Aplicaciones
- Routing
- Tipo de falla
El objetivo es minimizar interrupciones y acelerar la recuperación.
¿Qué es Preempt Mode?
Después de una falla, el Secondary puede convertirse en Active.
Cuando el Primary original vuelve a estar disponible podemos decidir si debe recuperar automáticamente el rol Active.
Eso es parte del comportamiento asociado con preemption.
Volver inmediatamente al Primary no siempre es lo mejor
Supongamos que el equipo Primary está inestable.
Falla.
Secondary toma el control.
Primary regresa.
Si recupera inmediatamente el rol y vuelve a fallar podemos generar cambios repetidos.
Por eso SonicWall recomienda especial cuidado con Preempt Mode cuando utilizamos Stateful HA.
Estabilidad puede ser más importante que “volver al equipo principal”
Después de un failover exitoso puede ser preferible mantener temporalmente el firewall que ya está operando correctamente y analizar la causa de la falla.
La política dependerá de la operación de la empresa.
¿Qué es Active/Active DPI?
Aquí aparece otra función que suele provocar confusión.
Active/Active DPI no significa que ambos SonicWall estén funcionando como dos routers independientes compartiendo todo el tráfico.
El firewall Active continúa manejando funciones como:
- Forwarding
- Firewall
- NAT
- Sesiones
Pero determinadas cargas de Deep Packet Inspection pueden descargarse hacia el segundo appliance.
¿Para qué sirve Active/Active DPI?
Puede ayudar cuando la inspección consume una cantidad importante de recursos.
Por ejemplo:
- IPS
- Gateway Anti-Virus
- Application Control
- SSL/TLS Inspection
El segundo appliance puede participar en el procesamiento de determinados flujos DPI.
Esto aprovecha hardware que normalmente estaría esperando
En Active/Standby tradicional, el segundo firewall está preparado para failover pero no procesa la carga normal.
Active/Active DPI permite utilizar parte de esa capacidad para inspección.
Es especialmente interesante cuando:
- Existe mucho tráfico HTTPS
- DPI-SSL está habilitado
- IPS tiene carga importante
- Application Control está activo
Pero Active/Active DPI tampoco duplica mágicamente todo el throughput
El Active sigue siendo responsable de gran parte del procesamiento de red.
El Secondary recibe determinados trabajos DPI y devuelve los resultados.
Debemos tratarlo como una función de offload, no como dos firewalls completamente independientes balanceando todo.
Active/Active DPI requiere diseño adicional
Necesitamos una interfaz física dedicada para el tráfico de offload DPI entre los appliances.
Por eso la disponibilidad de interfaces y la arquitectura física del modelo elegido importan.
¿TZ o NSa para High Availability?
Las dos familias pueden cubrir diferentes escenarios HA.
La familia TZ se orienta principalmente a:
- PyMES
- Sucursales
- Distributed Enterprise
La familia NSa proporciona mayor escala para:
- Corporativos
- Campus
- Sedes principales
- Data centers
- Más interfaces
- Mayor VPN
- Mayor escala
Consulta nuestra guía SonicWall TZ vs NSa
Escenario 1: oficina con TZ y aplicaciones críticas
Tenemos:
- 50 usuarios
- ERP cloud
- VoIP
- VPN
- Dos enlaces WAN
El tráfico cabe cómodamente en un TZ compatible.
Pero una falla del appliance detendría la operación.
En este escenario puede tener más valor invertir en:
dos TZ correctamente dimensionados en HA
que simplemente comprar un firewall considerablemente más grande sin redundancia.
Escenario 2: corporativo con NSa
Tenemos:
- Cientos de usuarios
- Múltiples VLAN
- DPI-SSL
- VPN
- Servidores
- Dos ISP
- Core multi-gigabit
Una pareja NSa puede proporcionar mayor resiliencia y, dependiendo de plataforma y licenciamiento, permitir funciones HA adicionales.
Consulta SonicWall NSa 2800 vs NSa 3800
Escenario 3: Dual WAN pero un solo firewall
La empresa cree tener alta disponibilidad porque tiene dos ISP.
Pero ambos llegan al mismo SonicWall.
En este caso HA ataca un riesgo completamente diferente:
la falla del firewall.
Escenario 4: HA pero un solo switch
Tenemos dos SonicWall correctamente configurados.
Pero ambas LAN terminan sobre un solo switch.
La disponibilidad del firewall mejoró.
La disponibilidad completa de la red todavía no.
Escenario 5: mantenimiento programado
HA también puede resultar útil aunque nunca tengamos una falla de hardware.
Podemos utilizarlo durante determinadas tareas de:
- Mantenimiento
- Actualización
- Diagnóstico
- Sustitución
reduciendo el impacto operativo cuando la arquitectura está correctamente diseñada.
¿HA sirve para actualizar firmware sin ninguna interrupción?
No deberíamos generalizar esa promesa.
La actualización debe seguir las recomendaciones específicas de SonicWall para la versión, modelo y método de upgrade.
HA puede reducir el impacto de mantenimiento, pero debemos planear la ventana y procedimiento correctamente.
¿Cómo monitorea SonicWall el par?
SonicOS proporciona una sección dedicada a High Availability donde podemos revisar:
- Primary
- Secondary
- Active
- Standby
- Links HA
- Licencias
- Estado
El monitoreo operativo es fundamental.
No sirve tener HA si el Secondary lleva meses con un problema
Un error peligroso consiste en instalar el par y no volver a revisar el secundario.
Debemos verificar periódicamente:
- Estado de sincronización
- Firmware
- Licencias
- HA Control Link
- HA Data Link
- Interfaces
- Alertas
La sincronización de configuración debe comprobarse
Los cambios realizados en el Primary normalmente se sincronizan hacia el Secondary.
Pero no deberíamos asumir que todo está sano solamente porque la GUI del Primary funciona.
El estado del par debe formar parte del monitoreo cotidiano.
HA debe probarse
Una arquitectura HA que nunca ha realizado un failover controlado no está completamente validada.
Durante una ventana de mantenimiento podemos comprobar:
- Failover Primary → Secondary
- Conectividad LAN
- Internet
- VPN
- Aplicaciones
- DNS
- VoIP
- Servicios publicados
- Failback
No empieces desenchufando cosas en producción sin plan
Una prueba HA debe tener:
- Ventana autorizada
- Backup de configuración
- Acceso administrativo
- Plan de rollback
- Lista de pruebas
- Responsable técnico
El objetivo es validar resiliencia sin crear una caída innecesaria.
Errores comunes al implementar SonicWall HA
1. Comprar modelos diferentes
El par necesita appliances idénticos.
2. Utilizar firmware diferente
Debemos mantener consistencia entre ambos equipos.
3. Confundir Active/Standby con Stateful
No son exactamente lo mismo.
4. Asumir que todas las sesiones sobrevivirán en modo stateless
Las sesiones activas pueden requerir renegociación.
5. No verificar licenciamiento Stateful
La disponibilidad depende del modelo y licencia.
6. No configurar monitoring correctamente
Podemos no detectar fallas relevantes o provocar failovers incorrectos.
7. Conectar ambos firewalls a un solo switch y asumir que toda la red es redundante
El switch continúa siendo un SPOF.
8. Pensar que Active/Active DPI equivale a load balancing completo
Es principalmente offload de inspección.
9. No monitorear el Secondary
Puede existir un problema oculto hasta el día del failover.
10. Nunca probar la conmutación
HA no probado es solamente una expectativa.
Checklist antes de implementar SonicWall HA
- Modelo exacto
- Segundo appliance idéntico
- Versión SonicOS
- Licencias
- Active/Standby requerido
- Stateful HA requerido
- HA Control Interface
- HA Data Interface
- Virtual MAC
- Interface Monitoring
- Logical Monitoring
- Preempt Mode
- WAN
- LAN
- VPN
- Switches
- UPS
- Servicios publicados
- Aplicaciones críticas
- Plan de pruebas
Preguntas que Sistro debería hacer antes de cotizar HA
- ¿Qué SonicWall tienes actualmente?
- ¿Qué firmware utilizas?
- ¿Cuánto tráfico procesa?
- ¿Qué ocurre si el firewall falla?
- ¿Cuánto downtime puedes tolerar?
- ¿Necesitas conservar sesiones activas?
- ¿Utilizas VPN?
- ¿Tienes dos proveedores de Internet?
- ¿Tienes switches redundantes?
- ¿Existe UPS?
- ¿Utilizas DPI-SSL?
- ¿Qué aplicaciones son críticas?
- ¿Necesitas Stateful HA?
- ¿Conviene Active/Active DPI?
- ¿Cuándo fue tu última prueba de failover?
SonicWall en Sistro
Firewalls SonicWall
https://sistro.net/firewalls-sonicwall
Catálogo SonicWall
https://sistro.net/sonicwall
Artículos relacionados de Biblioteca Virtual Sistro 2.0
SonicWall SD-WAN con Dual WAN y SLA Probes
SonicWall NSa 2800 vs NSa 3800
Recomendación final
SonicWall High Availability permite reducir uno de los riesgos más importantes de una infraestructura de seguridad:
que todo dependa de un único firewall.
Active/Standby proporciona redundancia del appliance.
Stateful HA agrega sincronización dinámica para reducir el impacto sobre conexiones existentes.
Y Active/Active DPI puede aprovechar capacidad del segundo equipo para determinadas cargas de inspección.
Pero HA no debe analizarse aislado.
Una arquitectura realmente resiliente debe considerar:
ISP + firewall + switching + energía + aplicaciones.
Comprar un segundo SonicWall no elimina automáticamente todos los puntos únicos de falla.
La pregunta correcta no es:
“¿Tengo dos firewalls?”
La pregunta correcta es:
“¿qué ocurre con mi operación cuando falla cada componente crítico de la red?”
¿Quieres implementar SonicWall High Availability?
En Sistro Networks podemos revisar tu modelo SonicWall, firmware, licencias, WAN, switching, VPN y aplicaciones críticas antes de diseñar un par HA.
También podemos apoyar con instalación, configuración, pruebas de failover, documentación y soporte.
Consulta y cotiza soluciones SonicWall con Sistro Networks
Preguntas frecuentes
¿Qué es SonicWall High Availability?
Es una arquitectura que utiliza dos firewalls compatibles para proporcionar redundancia y permitir que el segundo dispositivo tome el control ante determinadas fallas del activo.
¿Los dos SonicWall pueden ser modelos diferentes?
No. El par HA debe utilizar el mismo modelo y firmware compatible.
¿Qué diferencia existe entre Active/Standby y Stateful HA?
Active/Standby proporciona redundancia del appliance. Stateful HA agrega sincronización dinámica de estados para reducir el impacto sobre conexiones existentes durante el failover.
¿Stateful HA necesita licencia?
Dependiendo del modelo y plataforma puede requerir licenciamiento adicional. Debe comprobarse el appliance específico antes de cotizar.
¿Dual WAN sustituye High Availability?
No. Dual WAN proporciona redundancia de conectividad. HA proporciona redundancia del firewall.
¿High Availability elimina todos los puntos únicos de falla?
No. También debemos revisar switching, enlaces WAN, energía, storage y aplicaciones.
¿Qué es Virtual MAC?
Permite que los miembros del par compartan una identidad MAC virtual que puede ayudar a reducir tiempos de convergencia después de un failover.
¿Qué es Active/Active DPI?
Es una función que permite utilizar capacidad del firewall secundario para determinadas tareas de Deep Packet Inspection. No significa que ambos appliances reenvíen todo el tráfico de manera independiente.
¿Debo probar el failover?
Sí. Una implementación HA debería validarse mediante pruebas controladas de conectividad, VPN, aplicaciones y recuperación.
Deja un Comentario