Configurar Sophos Firewall High Availability (HA)

High Availability, o HA, conecta dos Sophos Firewalls en un clúster. El objetivo no es hacer que un solo firewall sea indestructible, sino manejar de manera controlada la falla de un dispositivo, puertos críticos individuales o el mantenimiento planificado.

Un entorno HA no es un sustituto para un buen diseño de red, copias de seguridad limpias y procesos de mantenimiento documentados. Un clúster mal planificado puede ser incluso más difícil de operar en caso de falla que un solo firewall. Por lo tanto, este artículo no solo explica dónde activar HA, sino cómo planificar, configurar, operar y verificar un clúster HA de Sophos Firewall de manera efectiva.

Índice de contenidos

• Resumen breve
• Video tutoriales
• Qué significa High Availability en Sophos Firewall
• Active-Passive o Active-Active
• Roles, estado y arquitectura
• Requisitos
• Planificación y diseño
• Preparar la configuración
• Configurar Active-Passive con QuickHA
• Configurar Active-Active con QuickHA
• Configuración manual de HA
• Validar el clúster
• Operación y mantenimiento
• Actualizaciones de firmware y copias de seguridad
• Resolución de problemas
• Listas de verificación de mejores prácticas

Resumen breve

En la mayoría de los entornos productivos, Active-Passive es la mejor variante de HA. Un firewall maneja todo el tráfico, el segundo firewall está listo para tomar el control en caso de falla o mantenimiento. El diseño es más simple, la licencia es más económica y el comportamiento en caso de falla es más fácil de entender.

Active-Active solo vale la pena si se aceptan conscientemente los límites y restricciones. No es un balanceo de carga simétrico clásico, donde ambos firewalls están en igualdad de condiciones en todas las partes de la red. El firewall primario sigue recibiendo el tráfico y distribuye ciertas conexiones al firewall auxiliar. No todos los servicios y tipos de tráfico se distribuyen.

Como orientación rápida:

• Máxima estabilidad y operación sencilla: Active-Passive.
• Usar la segunda firewall sin licencia de protección separada: Active-Passive.
• Se necesita más rendimiento para determinadas conexiones TCP: Evaluar Active-Active.
• Muchos casos VPN, proxy, RED, NDR o especiales: Preferir Active-Passive.
• Entorno pequeño o mediano sin problema claro de rendimiento: Active-Passive.
• Requisito claro de rendimiento y licenciamiento adecuado para ambas appliances: Active-Active tras prueba.

Video tutoriales

Los siguientes Sophos Techvids muestran visualmente HA en Sophos Firewall. Los videos no sustituyen una planificación correcta, pero ayudan a entender mejor QuickHA, los roles, los estados y el comportamiento básico de un clúster HA.

Qué significa High Availability en Sophos Firewall

Un clúster HA de Sophos Firewall consta de dos firewalls. Los dispositivos intercambian a través de un enlace HA dedicado heartbeats, estado del dispositivo, información de conexión y datos de configuración. La configuración se sincroniza desde el firewall primario al firewall auxiliar.

HA protege contra fallas típicas:

• Falla del firewall primario
• Fallo de energía o hardware
• Falla de una interfaz monitoreada
• Problema de software o servicio que hace que un dispositivo no funcione
• Actualizaciones de firmware planificadas
• Cambio de rol planificado durante el mantenimiento

Sin embargo, HA no resuelve todos los problemas:

• Una regla de firewall incorrecta sigue siendo incorrecta incluso en el clúster.
• Una falla de un switch compartido puede afectar a ambos firewalls simultáneamente.
• Un diseño de VLAN defectuoso o un concepto de enrutamiento incorrecto no se corrige automáticamente.
• Los registros y los informes no se sincronizan completamente entre ambos firewalls.
• Una copia de seguridad sigue siendo obligatoria.

Quien planifique HA debe haber aclarado previamente los fundamentos para zonas, interfaces, VLANs, LAGs y puentes. Para ello, consulte la guía Planificar y configurar zonas e interfaces de Sophos Firewall.

Active-Passive o Active-Active

Active-Passive

En Active-Passive, un firewall maneja todo el tráfico productivo. El segundo firewall está en modo pasivo y solo toma el control cuando el firewall activo falla o se activa un failover manualmente o por mantenimiento.

Características típicas:

• El firewall primario maneja el tráfico.
• El firewall auxiliar permanece en espera.
• Las sesiones se sincronizan en la medida en que el servicio lo admite.
• Solo el dispositivo con licencia necesita las suscripciones de protección en dispositivos de hardware.
• El firewall auxiliar toma el control en caso de failover con la misma dirección MAC virtual.
• Los dispositivos de red generalmente no necesitan volver a aprender sus vecindarios.

Active-Passive suele ser la mejor opción para entornos empresariales clásicos, sucursales, centros de datos y entornos donde la estabilidad es más importante que una posible ganancia de rendimiento.

Active-Active

En Active-Active, ambos firewalls manejan el tráfico. Sin embargo, la arquitectura sigue siendo asimétrica: el firewall primario recibe el tráfico y decide si procesa una conexión por sí mismo o la pasa al firewall auxiliar.

Sophos utiliza, entre otras cosas, la dirección IP de origen para la distribución. Las conexiones TCP de direcciones IP de origen pares se procesan típicamente en el primario, mientras que las direcciones IP de origen impares pueden ser redirigidas al auxiliar. El tráfico no TCP y ciertos servicios no se distribuyen de manera uniforme.

Características típicas:

• Ambos firewalls pueden manejar tráfico.
• El firewall primario sigue siendo el punto de entrada central.
• Ambos firewalls necesitan licencias adecuadas.
• No todos los servicios se distribuyen.
• Los registros y los informes se generan en el dispositivo que maneja el tráfico respectivo.
• La resolución de problemas es más compleja, ya que las conexiones pueden aterrizar en ambos nodos.

Active-Active es útil cuando hay un objetivo de rendimiento claro y se ha probado previamente si el tráfico relevante realmente se distribuye. Para alta disponibilidad pura, Active-Passive suele ser más limpio.

Roles, estado y arquitectura

Roles en el clúster HA

Valores de estado en operación

Dirección MAC virtual

Sophos Firewall utiliza direcciones MAC virtuales en el clúster HA para las interfaces productivas. Solo el primario responde a las solicitudes ARP para el clúster. En caso de failover, el auxiliar toma esta dirección MAC virtual. Esto mantiene la accesibilidad para switches, routers y clientes más estable, ya que la asignación de IP y MAC no cambia fundamentalmente.

Es importante la ID del clúster. Esta ID se utiliza para la dirección MAC virtual. Si se operan varios clústeres HA en el mismo entorno de capa 2, cada clúster debe tener una ID de clúster única. De lo contrario, pueden surgir conflictos de MAC.

Qué se sincroniza

• Reglas de firewall, policies, objetos, routing y configuración CLI se sincronizan del Primary al Auxiliary.
• Sesiones activas se sincronizan según protocolo y servicio.
• Secure Storage Master Key y credenciales de WebAdmin se sincronizan.
• Dedicated HA link no se sincroniza como una configuración normal de interfaz productiva.
• Peer Admin Port se trata por separado y no se sincroniza como una interfaz normal.
• Logs y reports no se sincronizan entre los dispositivos.

Comportamiento de failover

Un failover puede ser desencadenado por varios eventos:

• No hay más heartbeats a través del enlace HA
• Falla de un puerto monitoreado
• Corte de energía
• Falla de hardware
• Problema de software o servicio
• Cambio de rol planificado
• Actualización de firmware

Los heartbeats se ejecutan a través del enlace HA dedicado. Por defecto, se utilizan intervalos muy cortos. Si faltan varios heartbeats consecutivos, el par se considera no alcanzable. Luego, el firewall verifica el estado y realiza el cambio de rol.

En un failover, muchas conexiones se continúan o se reconstruyen rápidamente. Sin embargo, un failover no es completamente transparente para todas las aplicaciones. Especialmente las conexiones TCP con estado, las sesiones web, las conexiones proxy o ciertos escenarios de VPN pueden interrumpirse brevemente o necesitar ser reconstruidos.

Balanceo de carga en Active-Active

Active-Active no significa que ambos firewalls estén como dos routers iguales en la red. El firewall primario sigue siendo el punto de entrada central y distribuye ciertas conexiones al firewall auxiliar.

Puntos importantes:

• El balanceo de carga solo existe en Active-Active.
• El método no se puede ajustar libremente.
• Los balanceadores de carga externos frente a un clúster HA no se utilizan como diseño estándar para esta lógica HA de Sophos.
• No todo el tráfico se distribuye.
• El tráfico no TCP, SD-RED, el tráfico tunelado y algunas funciones de capa 7 pueden ser tratadas de manera diferente.
• La resolución de problemas debe incluir ambos nodos.

En la práctica, Active-Active solo debe usarse si se sabe de antemano qué tráfico está causando el cuello de botella y si ese tráfico se distribuye.

Servicios soportados y restringidos

Sophos HA admite la mayoría de los servicios de firewall. Sin embargo, algunos servicios tienen particularidades.

• Reglas de firewall y NAT se sincronizan. En Active-Active hay que saber qué nodo procesa una conexión.
• VPN funciona en muchos escenarios HA, pero no todos los tipos de sesión conmutan sin interrupción. IPsec puede asumir UDP/ICMP stateless mejor que TCP stateful.
• Web Protection funciona en el clúster. En Active-Active, las alertas pueden venir de ambos nodos.
• Email Protection puede comportarse de forma específica por nodo en quarantine y release, porque cada dispositivo guarda sus propios datos del mail traffic procesado.
• Synchronized Application Control no es adecuado para Active-Active si la función no está soportada en la versión SFOS utilizada.
• NDR Essentials debe planificarse en entornos HA solo con Active-Passive.
• sFlow solo se ejecuta en el Primary en entornos HA.
• Reports se generan localmente por dispositivo. Los reports agregados son más útiles mediante Sophos Central Firewall Reporting.
• Cellular WAN debe desactivarse para HA.
• Modelos XGS Wi-Fi no soportan HA.

Si los informes o la retención de registros son importantes, se debe planificar temprano si se utilizará un servidor Syslog externo o Sophos Central Firewall Reporting. Más información en Activar Central Firewall Reporting.

Requisitos

Antes de la implementación, se deben verificar cuidadosamente los requisitos de HA contra el entorno propio. Especialmente la igualdad de modelos, la versión de firmware, las interfaces, WAN celular y las plataformas virtuales son puntos donde pequeñas desviaciones pueden tener un gran impacto más adelante.

Compatibilidad de hardware y modelos

• Modelo de appliance: Ambas firewalls deben ser el mismo modelo XGS, por ejemplo XGS 2100 con XGS 2100.
• Revisión de hardware: Son posibles revisiones de hardware distintas con el mismo modelo XGS.
• Modelos XGS Wi-Fi: No soportados. Ejemplos: XGS 126w o XGS 136w.
• Flexi Port Module: Si se usan módulos de expansión, el número de Flexi Ports debe ser igual en ambos dispositivos.
• Firmware: Ambos dispositivos deben usar la misma versión SFOS, incluido Maintenance Release y Build.
• Hardware más appliance virtual: No es posible como par HA.

Appliances virtuales y de software

Las appliances virtuales o de software también deben coincidir muy bien entre sí.

• Plataforma: Mismo tipo de appliance y misma plataforma SFOS.
• Hypervisor: Mismo tipo de hypervisor.
• Recursos: Mismos CPU cores, recursos comparables y mismo número de interfaces de red.
• Firmware: Misma versión SFOS, incluido Build.
• Direcciones MAC: En entornos virtuales, la opción de direcciones MAC asignadas por el hypervisor puede ser relevante para no requerir Promiscuous Mode. Un cambio causa downtime.

Implementaciones en la nube

En entornos en la nube, se aplican requisitos adicionales de plataforma. El enrutamiento, las interfaces virtuales, las direcciones IP, los grupos de seguridad, los UDR o los mecanismos de failover específicos de la nube deben coincidir con el diseño de la nube respectiva. El enfoque HA normal de la appliance no se puede transferir sin verificar a Azure, AWS u otros entornos en la nube.

Si se opera un Sophos Firewall en la nube, se debe verificar la documentación actual de Sophos para la plataforma respectiva y la arquitectura de red en la nube antes de planificar HA.

Licenciamiento y registro

El licenciamiento de HA varía según la plataforma y el modo HA. Tres preguntas son cruciales: ¿Se trata de hardware o virtual/software? ¿Se utiliza Active-Passive o Active-Active? ¿Y cuál es el dispositivo Initial Primary, es decir, el dispositivo que tiene la licencia para el clúster? Estos puntos deben verificarse antes de la implementación con el estado de la licencia, los números de serie y el modo objetivo.

Los puntos de licencia más importantes:

• Base Firewall: Para HA se requiere una licencia Base Firewall. Las hardware appliances tienen esta licencia por defecto. Las virtual/software appliances deben estar licenciadas de forma adecuada.
• Active-Passive Hardware: Solo el dispositivo Initial Primary necesita las Subscriptions productivas. La Auxiliary Firewall recibe una copia de las Subscriptions y puede procesar tráfico después de un failover.
• Active-Active Hardware: Ambas firewalls necesitan sus propias licencias adecuadas. Los tipos de licencia deben coincidir; las fechas de expiración pueden ser diferentes.
• Active-Passive Virtual/Software: Solo el Primary necesita las licencias necesarias, incluida Base Firewall.
• Active-Active Virtual/Software: Ambos dispositivos necesitan su propia licencia Base Firewall y las demás licencias de protección adecuadas.
• Registro Hardware: Ambos dispositivos de hardware deben estar registrados en Sophos Central o en el Sophos Licensing Portal y poder sincronizar sus licencias.
• Registro Virtual/Software Active-Passive: En Active-Passive Virtual/Software, según Sophos, solo se reclama el Primary.
• Sophos Central Management: La sincronización de licencias y el claiming no significan automáticamente que las firewalls también se gestionen mediante Sophos Central Firewall Management. Para ello se necesita una Subscription adicional adecuada.
• RMA y soporte: Para sustitución de hardware y Advance Replacement, el estado de soporte es importante. En Active-Passive Hardware, Sophos menciona Enhanced Plus Support en el dispositivo Primary como requisito relevante para Advance Hardware Replacement. En Active-Active, el estado de soporte debe encajar en ambos dispositivos.

Importante: En Active-Passive, el Initial Primary es especialmente importante porque este dispositivo tiene la licencia para el clúster. En la vista HA, el dispositivo correspondiente indica que tiene la licencia para el clúster. En caso de duda, el dispositivo debe documentarse claramente en el manual de operación.

Si las licencias en Active-Active no coinciden, según Sophos, primero se detiene el balanceo de carga. Si la discrepancia persiste, HA puede desactivarse. En una configuración inicial, Active-Active HA no se activa correctamente con licencias no coincidentes. Por lo tanto, una verificación de licencia es obligatoria en la rutina de operación.

En appliances virtuales/software, la licencia de Base Firewall es especialmente crítica. Si se desactiva o el Initial Primary no puede sincronizar la licencia durante un período prolongado, HA puede desactivarse y otras funciones de protección se desactivarán. Aquí es relevante una sincronización con el servidor de licencias al menos una vez cada 90 días. Para entornos productivos, esto significa: El clúster HA no solo debe funcionar técnicamente, sino también poder alcanzar regularmente el servidor de licencias.

Para la operación, se debe documentar al menos:

• qué dispositivo es el Initial Primary
• qué números de serie o IDs de appliance pertenecen al clúster
• qué licencias están activas en qué dispositivo
• cuándo se sincronizaron las licencias por última vez
• qué nivel de soporte está disponible para RMA o reemplazo avanzado
• quién autoriza cambios de licencia, renovaciones y procesos de RMA

Requisitos de red

• HA-Link: Conexión dedicada entre ambas firewalls, idealmente directa con cable Ethernet.
• HA-Link-Zone: Zona DMZ con SSH activado para la zona.
• HA-Link-IP-Adressen: Direcciones IP estáticas en la misma subred, pero direcciones distintas.
• Calidad del HA-Link: Alto ancho de banda, baja latencia y sin pérdida de paquetes.
• Switches: Activar RSTP en switches conectados a puertos de firewall.
• Monitored Ports: Monitorizar solo puertos realmente conectados y críticos.
• Cellular WAN: Desactivar para HA.
• Peer Admin Port: Planificar por separado para que la Auxiliary Firewall siga siendo accesible.

El enlace HA no maneja tráfico normal de clientes o servidores. Solo es relevante para heartbeats, estado, sincronización de sesiones, sincronización de configuraciones y distribución Active-Active. Sin embargo, es extremadamente crítico. Si el enlace HA falla, ambos firewalls pueden creer que son primarios. Este escenario de “split-brain” debe evitarse.

El Peer Admin Port es un acceso operativo propio hacia la Auxiliary Firewall. Los puertos de administración de ambos dispositivos deben estar en la misma subred, pero usar direcciones IP distintas. Después de crear HA, la Auxiliary Firewall solo se alcanza mediante esta Peer-Admin-Adresse y solo desde una red adecuada. Si ambos dispositivos todavía usan la misma default IP o los Admin Ports están en subredes distintas, HA falla o la Auxiliary no queda accesible de forma limpia.

Puertos e interfaces

• Dedicated HA link: Heartbeat, estado y sincronización de configuración y sesiones. Conectar directamente o mediante un switch muy fiable. No usar para tráfico productivo.
• Monitored ports: Monitorización de enlaces productivos críticos. Monitorizar WAN, DMZ importantes o core uplinks, pero no seleccionar puertos no usados.
• Peer Admin Port: Acceso al WebAdmin de la Auxiliary. Planificar y documentar por separado; el cliente debe estar en la subred adecuada.
• Interfaces productivas: Cablear LAN, WAN, DMZ, VLANs y LAGs de forma idéntica en ambas firewalls y diseñarlas de forma equivalente.

Como enlace HA dedicado, son posibles interfaces físicas, VLANs o LAGs. Las interfaces de puente y las direcciones IP alias no se pueden usar como enlace HA dedicado. Si se utiliza un LAG como enlace HA, las interfaces principales deben estar configuradas de manera idéntica en ambas appliances.

Importante: el Dedicated HA link y un Monitored Port no pueden ser la misma interfaz. Si una interfaz ya se usa en una configuración productiva y aun así se elige como HA-Link, la firewall puede cambiar o eliminar configuraciones dependientes de la interfaz. Por eso el HA-Link debe estar libre y documentado de antemano.

Planificación y diseño

Topología recomendada para Active-Passive

Un diseño típico de Active-Passive se ve así:

• ambos firewalls están en el mismo rack o en racks cercanos
• todas las interfaces productivas están cableadas de manera idéntica
• WAN se conecta a switches redundantes o transiciones de proveedor bien documentadas
• LAN/DMZ se conectan a estructuras de switches redundantes
• el enlace HA está conectado directamente
• se prevé un acceso de administración o administración separado
• los puertos WAN y Core/DMZ se definen como puertos monitoreados

El punto más importante: El segundo firewall debe poder asumir la misma posición de red en caso de falla. Por lo tanto, los VLANs, trunks, LAGs, puertos de switch y conexiones de proveedor deben planificarse de manera consistente.

Topología recomendada para Active-Active

Active-Active requiere la misma limpieza física que Active-Passive, pero además una expectativa clara sobre el tráfico que se puede distribuir.

Antes de Active-Active, se debe responder:

• ¿Qué tráfico es el cuello de botella?
• ¿Se distribuye exactamente ese tráfico en Active-Active?
• ¿Ambas appliances están completamente y adecuadamente licenciadas?
• ¿Están preparados los procesos de registros, informes y resolución de problemas para ambos nodos?
• ¿Existen servicios como VPN, NDR, Control de Aplicaciones Sincronizado o escenarios de proxy que desaconsejen Active-Active?

Sin una respuesta clara, Active-Passive es la mejor opción.

LAN, WAN, DMZ y enlace HA

• LAN: Zonificar redes internas de forma limpia. Planificar VLANs no solo técnicamente, sino también desde la seguridad.
• WAN: Considerar conexión del proveedor, failover gateways y SD-WAN por separado de HA. HA no sustituye un concepto de redundancia WAN.
• DMZ: Mantener redes de servidores y publicaciones externas separadas de redes de clientes.
• HA-Link: Conexión propia, direccionamiento estático, zona DMZ, SSH permitido para DMZ. No llevar comunicación de usuarios o servidores por este enlace.
• Management: Restringir conscientemente acceso de administración, Device Access y ACLs.

Para asegurar los servicios locales de firewall, consulte Asegurar el acceso a Sophos Firewall: Configurar correctamente Device Access.

Requisitos de los switches

Los switches son a menudo el factor de riesgo invisible en HA. Un clúster HA solo funciona tan bien como el entorno de capa 2 debajo de él.

Recomendaciones:

• Activar RSTP en los switches involucrados.
• Configurar trunks de manera idéntica en ambos firewalls.
• Permitir VLANs de manera consistente en todos los puertos involucrados.
• Construir LAGs de manera idéntica.
• No seleccionar puertos monitoreados a medio terminar o no utilizados.
• Conectar el enlace HA directamente si es posible.
• Si el enlace HA pasa por switches, la ruta debe ser estable, de baja latencia y sin pérdida de paquetes.

VLANs, LAGs, puentes y RED

VLANs y LAGs son posibles en HA, pero aumentan los requisitos de planificación. El clúster HA no debería ser el primer lugar donde se pruebe un diseño de VLAN o LAG.

• VLAN: Planificar de forma idéntica en ambos dispositivos. Tener en cuenta la parent interface. VLAN como HA-Link es posible, pero solo con un diseño muy limpio.
• LAG: Útil para core uplinks o conexión redundante a switches. Las parent interfaces deben ser consistentes.
• Bridge: HA en Bridge Mode está soportado, pero hace más complejo el troubleshooting. Para diseños nuevos, Gateway Mode suele ser más transparente.
• RED: Escenarios RED y remotos pueden influir en HA, especialmente si las redes se extienden entre ubicaciones. Probar antes rendimiento, latencia y patrones de error.
• VPN: El VPN failover funciona de forma distinta según protocolo y tipo de sesión. Probar IPsec y Remote Access por separado.

Evitar el “split-brain”

“Split-brain” significa que ambos firewalls creen que son activos o responsables de manera independiente. Esto puede suceder si el enlace HA falla, pero los dispositivos aún están en la red de producción.

Medidas:

• No llevar el enlace HA a través de rutas de switch inseguras o inestables.
• Preferir la conexión directa para el enlace HA.
• Seleccionar conscientemente los puertos monitoreados.
• Configurar RSTP de manera limpia.
• No realizar cableado asimétrico.
• Verificar el estado de HA después de cada cambio de switch o VLAN.
• Ajustar los valores de keepalive solo con razón.

Preparar la configuración

Antes de configurar HA, no se debe improvisar en la red de producción. Esta preparación ahorra mucho tiempo más adelante.

Preparación de ambos firewalls

• Llevar ambos firewalls a la misma versión de SFOS, incluida la compilación.
• Verificar el estado de licencia y registro.
• Desactivar WAN celular.
• Asegurarse de que los modelos sean compatibles.
• Verificar la configuración de los puertos Flexi.
• Documentar interfaces y puertos de switch.
• Establecer el puerto de enlace HA.
• Conectar directamente el enlace HA o verificar la ruta del switch.
• Planificar la zona DMZ y el acceso SSH para el enlace HA.
• Documentar el acceso de administración a ambos dispositivos.
• Crear una copia de seguridad de la configuración existente.

Las copias de seguridad no son opcionales en HA. Antes de la configuración, antes de las actualizaciones de firmware y antes de cambios importantes en las interfaces, se debe tener una copia de seguridad. Los fundamentos están en Crear o restaurar una copia de seguridad de Sophos Firewall.

Antes de hacer clic en Initiate HA, debe comprobarse además:

• Admin Ports en la misma subred, pero con IPs distintas: De lo contrario, HA no se puede crear correctamente o la Auxiliary no será accesible después.
• Dedicated HA link sin dependencias productivas: HA puede cambiar direcciones IP de interfaces y configuraciones dependientes.
• Monitored Ports conectados en ambos dispositivos: Un Monitored Port sin conexión puede impedir el clúster o disparar failover de inmediato.
• Cluster ID única: Varios clústeres HA en el mismo segmento Layer 2 necesitan MACs virtuales distintas.
• Backup, SSMK y firmware build documentados: En restore, RMA o reimage, el clúster debe poder reproducirse.

QuickHA o configuración manual

• QuickHA: Caso estándar. Rápido, robusto y suficiente para la mayoría de configuraciones Active-Passive y Active-Active.
• Configuración manual: Útil cuando Admin Ports, HA-Link, Cluster ID, peer addresses y valores de detalle deben definirse conscientemente.

QuickHA detecta el par a través de las interfaces de enlace HA elegidas. Una vez que los dispositivos se encuentran, se construye el clúster. La frase de contraseña se utiliza para establecer el túnel SSH cifrado y luego no se trata como una contraseña reutilizable. Si se reemplaza un dispositivo, se debe desactivar HA y configurarlo nuevamente.

Los pasos descritos aquí se basan en la configuración oficial de HA de Sophos, pero están formulados conscientemente como una lista de verificación práctica para administradores. Para cambios productivos, no solo se debe hacer clic en el asistente, sino documentar roles, enlace HA, acceso de administración, copia de seguridad, estado de licencia y ruta de retorno de antemano.

Configurar Active-Passive con QuickHA

1. Preparar el firewall primario

1. Iniciar sesión en WebAdmin en el firewall que será primario.
2. Ir a System services > High availability.
3. Seleccionar el modo Primary (active-passive).
4. Usar QuickHA.
5. Opcionalmente, asignar un nombre de nodo, por ejemplo, FW01.
6. Establecer una frase de contraseña para HA.
7. Guardar la frase de contraseña de manera segura, ya que se necesitará en el firewall auxiliar.
8. Seleccionar el enlace HA dedicado.
9. Iniciar Initiate HA.

Notas:

• El enlace HA no debe tener dependencias productivas.
• Si QuickHA utiliza una interfaz no vinculada, Sophos asigna a esta interfaz la zona DMZ y establece configuraciones específicas de HA.
• El enlace HA utiliza direcciones IP estáticas en el rango de enlace local si QuickHA utiliza los valores predeterminados.
• Se debe permitir SSH para la zona de enlace HA, ya que el túnel HA se establece a través de ella.

2. Preparar el firewall auxiliar

1. Iniciar sesión en el firewall que será auxiliar.
2. Ir a System services > High availability.
3. Seleccionar el rol Auxiliary.
4. Usar QuickHA.
5. Opcionalmente, asignar un nombre de nodo, por ejemplo, FW02.
6. Ingresar la misma frase de contraseña para HA.
7. Seleccionar el mismo puerto de enlace HA que en el lado primario.
8. Iniciar Initiate HA.

Después de la configuración, el firewall primario sincroniza la configuración en el firewall auxiliar. En el firewall auxiliar, se sobrescriben muchas configuraciones locales. Por lo tanto, el auxiliar no debe configurarse en paralelo como un firewall productivo independiente antes de la configuración de HA.

3. Verificar configuraciones avanzadas

Después de construir el clúster, no se debe simplemente hacer clic para salir, sino verificar los siguientes puntos:

• Estado de HA de ambos nodos
• Rol y estado en la parte superior derecha de WebAdmin
• Enlace HA dedicado
• Puertos monitoreados
• Puerto de administración del par
• Primario preferido
• Intervalo de keepalive e intentos
• Titular de la licencia en Active-Passive
• Registro en Sophos Central, si se utiliza

4. Establecer puertos monitoreados

Los puertos monitoreados determinan si una falla de interfaz desencadena un failover. Candidatos típicos:

• Enlace WAN
• Enlace LAN principal
• Enlaces DMZ o de servidor importantes

No se deben monitorear puertos que a veces están intencionalmente fuera de línea, no están cableados o solo se utilizan para escenarios opcionales. Un puerto monitoreado incorrectamente es una causa común de failover inesperado o un clúster que no se inicia.

Configurar Active-Active con QuickHA

Active-Active se configura de manera similar, pero con un objetivo diferente. Antes, ambos firewalls deben estar adecuadamente licenciados.

1. Verificar previamente

• Ambos firewalls tienen licencias adecuadas.
• Los tipos de licencia coinciden.
• Ambos dispositivos están registrados.
• Ambos dispositivos ejecutan la misma versión de SFOS, incluida la compilación.
• El tráfico relevante realmente se beneficia de Active-Active.
• Se han verificado los servicios con restricciones de Active-Active.
• El monitoreo y la resolución de problemas están preparados para ambos nodos.

2. Configurar el firewall primario

1. Ir a System services > High availability.
2. Seleccionar Primary (active-active).
3. Usar QuickHA.
4. Asignar un nombre de nodo.
5. Establecer una frase de contraseña para HA.
6. Seleccionar el enlace HA dedicado.
7. Iniciar HA.

3. Configurar el firewall auxiliar

1. En el segundo dispositivo, ir a System services > High availability.
2. Seleccionar Auxiliary.
3. Usar QuickHA.
4. Ingresar la misma frase de contraseña.
5. Seleccionar el mismo puerto de enlace HA.
6. Iniciar HA.

4. Probar después de la configuración

En Active-Active, se debe probar más que solo el estado de HA:

• ¿Se distribuyen las conexiones en ambos nodos?
• ¿Son visibles los registros en ambos dispositivos?
• ¿Funcionan las conexiones VPN después de un cambio de rol?
• ¿Funcionan la protección web, IPS, control de aplicaciones y las características de seguridad relevantes?
• ¿Hay aplicaciones que se comportan de manera asimétrica?
• ¿Se generan informes y alertas como se espera?

Configuración manual de HA

La configuración manual de HA es útil cuando la lógica automática de QuickHA no ofrece suficiente control.

Razones típicas:

• se deben usar direcciones IP fijas para el enlace HA
• se debe definir exactamente el puerto de administración del par
• se debe establecer conscientemente la ID del clúster
• existen varios clústeres HA en el mismo entorno de capa 2
• se deben operar appliances virtuales con ciertas opciones de MAC
• se necesita un despliegue muy controlado

En la configuración manual, primero se prepara el firewall auxiliar y luego se configura el firewall primario. El primario debe conocer la dirección IP del enlace HA del par.

Campos importantes:

• Operation mode: Active-Passive o Active-Active.
• Initial device role: Primary o Auxiliary.
• Dedicated HA link: Interfaz para heartbeat, estado y sincronización.
• Peer HA link IPv4: Dirección de la interfaz HA-Link en el segundo dispositivo.
• Cluster ID: Base para direcciones MAC virtuales. Definir de forma única si hay varios clústeres.
• Monitored ports: Puertos críticos cuya caída debe disparar un failover.
• Peer administration settings: Acceso a la Auxiliary Firewall.
• Preferred primary: Dispositivo que debe volver a ser Primary después de un failover.
• Keepalive interval / Attempts: Sensibilidad de la detección HA. Ajustar solo conscientemente.

Validar el clúster

Después de la configuración, se debe verificar sistemáticamente el clúster HA.

Verificación de WebAdmin

1. Iniciar sesión en el firewall primario.
2. Verificar el estado de HA en la parte superior derecha.
3. Ir a System services > High availability.
4. Verificar roles, estado, números de serie y modo.
5. Asegurarse de que el clúster esté sincronizado.
6. En Active-Passive, verificar qué dispositivo tiene la licencia para el clúster.

Verificación de CLI

En la consola del dispositivo, se puede mostrar el estado de HA:

system ha show details

Si no está claro qué dispositivo es el Initial Primary con licencia, este valor puede ayudar en la Advanced Shell:

nvram get "#li.master"

YES indica el dispositivo primario inicial, NO el dispositivo auxiliar. Estos comandos deben documentarse y solo usarse en casos claros de mantenimiento o diagnóstico.

Si el acceso a la shell aún no está preparado, la guía Conectar Sophos Firewall por SSH puede ser útil.

Prueba funcional

• Probar un cliente desde la LAN hacia Internet.
• Probar el acceso a servidores internos.
• Probar VPN.
• Probar escenarios DNAT o WAF.
• Probar DNS y DHCP, si el firewall proporciona estos servicios.
• Verificar registros en el visor de registros.
• Probar el cambio de rol de HA en una ventana de mantenimiento.
• Luego documentar roles, estado y comportamiento de sesiones.

Operación y mantenimiento

Monitoreo continuo

Un clúster HA debe ser monitoreado activamente. Solo porque haya dos firewalls en el rack, el entorno no es automáticamente altamente disponible.

Se deben monitorear:

• Estado de HA
• Estado de roles Primario/Auxiliar
• Enlace HA
• Puertos monitoreados
• Estado de licencias y suscripciones
• Versiones de firmware
• Recursos como CPU, RAM, disco
• Servicios centrales como IPS, Web, VPN, DNS, DHCP
• Registros en el visor de registros
• Alertas en Sophos Central o por correo electrónico

Para temas de disco y hardware, se deben considerar ambos nodos por separado. Los informes locales, los archivos de registro y el estado de SSD pueden diferir. Los artículos Verificar espacio de almacenamiento y gestionar informes en Sophos Firewall y Verificar salud de SSD en Sophos Firewall mediante SMART son útiles.

Registros e informes

Los registros e informes no se fusionan simplemente en un único conjunto de datos local. Cada dispositivo escribe registros para el tráfico que maneja. En Active-Active, esto es especialmente importante, ya que el tráfico puede aparecer en ambos nodos.

Sophos Central Firewall Reporting es útil en entornos HA, ya que puede analizar datos de múltiples firewalls de manera centralizada. Los registros de resolución de problemas locales se encuentran en el propio firewall. El artículo Resolución de problemas en Sophos Firewall: Servicios y registros explica qué servicios y archivos de registro son relevantes para los análisis.

Manual de operación para HA

Un clúster HA necesita un manual de operación breve. Debe indicar qué dispositivo es el Initial Primary, qué puertos se monitorean, cómo acceder al auxiliar, quién autoriza las actualizaciones de firmware y cuándo se desactiva HA para intercambio o reimagen.

Documentar al menos:

• Número de serie, ubicación, posición en el rack y rol de ambas appliances.
• Enlace HA dedicado, puerto de administración del par, ID del clúster y puertos monitoreados.
• Primario preferido y comportamiento esperado después de un failover.
• Titular de la licencia, estado de soporte y contacto para RMA.
• Procedimiento para actualización de firmware, copia de seguridad, reimagen e intercambio de hardware.
• Persona responsable de registros, Central Reporting, Syslog y casos de soporte.

Si solo el WebAdmin en un nodo falla, no significa automáticamente que todo el clúster HA esté defectuoso. Entonces, se debe verificar específicamente si un reinicio de la GUI de WebAdmin o un reinicio controlado del servicio es suficiente antes de activar un failover o reinicio.

Cambios en el clúster

Los cambios de configuración se realizan en el firewall primario. El firewall auxiliar no es el lugar para cambios normales de reglas, interfaces o políticas.

Antes de cambios importantes:

• Crear una copia de seguridad.
• Definir una ventana de mantenimiento.
• Verificar el estado de HA.
• Actualizar la documentación.
• Establecer una ruta de reversión.
• Después del cambio, probar la sincronización y el tráfico.

Esto es especialmente importante para:

• Interfaces
• VLANs
• LAGs
• Zonas
• Enrutamiento
• NAT
• VPN
• Device Access
• SD-WAN

Actualizaciones de firmware y copias de seguridad

Actualizaciones de firmware en entornos HA

Las actualizaciones de firmware se inician en el firewall primario. Los dispositivos se actualizan uno tras otro, y el clúster puede cambiar de roles durante el proceso.

Proceso típico:

1. Iniciar la actualización en el firewall primario.
2. El firewall auxiliar se actualiza.
3. El firewall auxiliar se reinicia y toma el control temporalmente.
4. El primario anterior se actualiza.
5. El primario anterior se reinicia.
6. Si el primario preferido está activo, puede ocurrir un cambio de regreso al dispositivo preferido.

Sin embargo, se debe planificar una ventana de mantenimiento para las actualizaciones de firmware. Aunque el proceso está diseñado para minimizar el tiempo de inactividad, algunas sesiones, conexiones VPN o aplicaciones especiales pueden reaccionar brevemente.

Para la preparación, consulte Actualización de firmware de Sophos Firewall - Preparación y mejores prácticas.

Actualizaciones de patrones

Las actualizaciones de patrones se instalan en el firewall primario y se sincronizan con el firewall auxiliar. Esto también se aplica a entornos donde las actualizaciones se controlan o se aplican sin conexión.

Si un clúster HA se opera en un entorno aislado, antes de cada actualización manual de patrones o licencia, debe estar claro qué nodo es el Initial Primary y qué nodo es actualmente el primario. El procedimiento de Air-Gap se describe en Operar licenciamiento y actualizaciones de patrones de Sophos Firewall en Air-Gap.

Copia de seguridad y restauración

La copia de seguridad y restauración tienen particularidades en entornos HA:

• Las copias de seguridad deben crearse regularmente y antes de cada cambio importante.
• La restauración se realiza en el firewall primario actual.
• Después de la restauración, ambos firewalls se desregistran de Sophos Central y deben registrarse nuevamente.
• La restauración causa reinicio y tiempo de inactividad, no un failover normal.
• Si se restaura una copia de seguridad sin configuración de HA en un clúster HA, HA se desactiva y debe reconstruirse.

Reemplazo de un nodo del clúster

Al reemplazar o reimaginar un nodo, no se debe simplemente dejar que HA continúe con el par antiguo.

Puntos importantes:

• Sophos distingue en el proceso RMA si se sustituye la Auxiliary o la Primary.
• RMA y reimage en Active-Passive causan downtime planificado y no deben tratarse como un failover normal.
• Antes de reimaginar o reemplazar, desactivar HA de manera limpia.
• Documentar la versión de firmware y la compilación.
• Crear una copia de seguridad.
• Identificar al titular de la licencia.
• Eliminar el dispositivo de Sophos Central Management si se devuelve o reemplaza.
• Registrar el nuevo dispositivo.
• Configurar HA nuevamente, ya que la frase de contraseña antigua de HA no se reutiliza para un nuevo dispositivo.

Si se sustituye la Auxiliary, la Primary sana suele seguir funcionando primero como dispositivo HA standalone. Si se sustituye la Primary, debe aclararse con especial cuidado qué dispositivo era el Initial Primary, qué backup se usa y cuándo se cambian los cables al dispositivo de reemplazo. En ambos casos deben documentarse modelo, hardware revision, firmware version, build, license transfer, estado de Sophos Central y estado de msync. El servicio y el log correspondiente se clasifican en Troubleshooting de Sophos Firewall: Services y Logs.

Para la nueva instalación técnica, consulte Reinstalar Sophos Firewall OS: Reimagen con USB. Si hay un defecto de hardware o un proceso de RMA en juego, también se debe planificar Preparar correctamente un defecto técnico de hardware de Sophos y RMA.

Resolución de problemas

En caso de problemas profundos, se debe mantener la estructura: primero verificar el estado, el enlace HA, los puertos monitoreados, la versión de firmware y el estado de la licencia, y luego recurrir a casos especiales o indicaciones del fabricante. Así se mantiene claro si hay un problema real de HA o si la licencia, la interfaz, la versión de firmware o el monitoreo están causando el error.

Registros importantes y lugares de diagnóstico

• Estado HA: System services > High availability.
• Event Logs: Log viewer > System.
• Troubleshooting Logs: Diagnostics > Tools o por SSH en /log.
• Detalles HA en CLI: system ha show details.
• Problemas de interfaz: show network interfaces, ifconfig, dmesg en diagnósticos adecuados.
• Titular de licencia: Vista HA de WebAdmin o nvram get "#li.master".

Para análisis más profundos, a menudo es útil el artículo Resolución de problemas en CLI de Sophos Firewall: comandos importantes.

Errores HA típicos

• El clúster no se forma, firmware version o build diferentes: Revisar la versión en ambos dispositivos y llevar ambas firewalls a la misma versión SFOS.
• El clúster no se forma, modelo o appliance no encaja: Revisar modelo y número de serie. Para hardware HA, usar solo modelos XGS compatibles e iguales.
• HA could not be enabled: Es posible que el Dedicated HA link no esté conectado o que el peer no sea alcanzable. Revisar port status, cable, switch y ping a la HA-Link-IP; después estabilizar cableado o HA-Link.
• HA-Link down: Cable, switchport, VLAN o LAG puede estar defectuoso. Revisar interface status, speed/duplex, VLAN trunk y miembros LAG.
• Ambos dispositivos pasan a Standalone: El HA-Link ha fallado, con riesgo de split-brain. Revisar conexión física del HA-Link y ruta de switch, apagar un dispositivo de forma controlada, reparar HA-Link y volver a iniciarlo.
• Auxiliary WebAdmin no accesible: Peer Admin Port, subnet, route o Device Access no encajan. Revisar Admin-Port-IP y acceso desde la management network.
• Validation failed for HA interface IP: Admin Ports o HA-Link addresses no están en la subred esperada. Revisar direcciones IP y /log/syslog.log, y corregir direccionamiento.
• Failover inesperado: A menudo un Monitored Port ha caído o fue seleccionado erróneamente. Revisar Monitored Ports y estado de switch, y monitorizar solo puertos realmente críticos y estables.
• Failover no ocurre: Probablemente el puerto relevante no está monitorizado. Añadir WAN, core o DMZ ports críticos como Monitored Ports.
• Active-Active no distribuye como se espera: Puede que el tipo de tráfico no sea load-balanced. Revisar tipo de conexión, protocolo y logs de ambos nodos; si el beneficio no está claro, usar Active-Passive o ajustar el diseño.
• Logs aparentemente ausentes: El tráfico quizá fue procesado por el otro nodo o logging no está activo. Revisar ambos nodos y Log Viewer, activar logging en reglas y usar Central Reporting o Syslog.
• Reports diferentes: Los reports locales son específicos por nodo. Comparar reports de ambos dispositivos o usar Sophos Central Firewall Reporting.
• Problema de licencia en Active-Active: Es posible que los tipos de licencia no coincidan. Revisar licensing en ambas firewalls y alinear licencias.
• Problemas tras firmware update: Un nodo no se actualizó correctamente o el clúster no está sincronizado. Revisar HA status, firmware versions y logs; en clústeres productivos usar ventana de mantenimiento e involucrar Sophos Support.
• Flexi-Port-HA-Link no funciona: Speed/duplex o auto-negotiation no encajan. Revisar Interface Advanced settings en ambos dispositivos y configurar ambos lados igual o usar un puerto fijo.

Procedimiento en caso de falla del enlace HA

Si el enlace HA dedicado falla, se debe tener cuidado. Ambos firewalls pueden no verse entre sí. En el peor de los casos, ambos dispositivos envían ARP/GARP e intentan reclamar la MAC del clúster para sí mismos.

Procedimiento seguro:

1. Estabilizar el estado de la red.
2. Decidir qué dispositivo debe permanecer activo.
3. Apagar el otro dispositivo de manera controlada o desconectarlo de la red de producción.
4. Reparar cable, puerto de switch, VLAN o LAG del enlace HA.
5. Reiniciar el dispositivo.
6. Verificar el estado de HA.
7. Controlar registros y roles.

Comandos CLI relevantes

system ha show details

Muestra detalles de HA en la consola del dispositivo.

show network interfaces

Ayuda con el estado de la interfaz y la información del enlace.

nvram get "#li.master"

Muestra en la Advanced Shell si el dispositivo es el Initial Primary con licencia.

dmesg | grep PortE

Puede dar pistas sobre flaps de enlace en ciertos problemas de hardware/interfaz.

No todos los comandos pertenecen a cada entorno. Para sistemas productivos, se aplica: Primero documentar el estado, luego verificar específicamente.

Listas de verificación de mejores prácticas

Planificación

• Evaluar Active-Passive como variante estándar.
• Usar Active-Active solo con un objetivo de rendimiento claro.
• Verificar ambos dispositivos en cuanto a modelo, firmware, puertos Flexi y licenciamiento.
• Conectar el enlace HA de manera dedicada y lo más directamente posible.
• Seleccionar conscientemente los puertos monitoreados.
• Planificar el acceso de administración en el primario y el auxiliar.
• Documentar claramente la ID del clúster.
• Documentar diseño de switches, VLANs y LAGs.
• Planificar RSTP en switches relevantes.
• Considerar el escenario de “split-brain”.
• Documentar el proceso de copia de seguridad y restauración.

Implementación

• Crear una copia de seguridad antes.
• Llevar ambos firewalls a la misma versión de SFOS.
• Desactivar WAN celular.
• Preparar el enlace HA con direccionamiento estático y zona DMZ.
• Permitir SSH para la zona de enlace HA.
• Nombrar claramente el primario y el auxiliar.
• Usar la frase de contraseña solo para la configuración y luego no tratarla como contraseña de administrador permanente.
• Verificar configuraciones avanzadas después de QuickHA.
• Establecer puertos monitoreados solo cuando esté claro qué enlaces son estables y críticos.
• Probar failover en una ventana de mantenimiento.

Operación

• Verificar regularmente el estado de HA.
• Monitorear licencias y sincronización.
• Realizar actualizaciones de firmware solo preparadas y con ventana de mantenimiento.
• Probar copias de seguridad regularmente.
• Realizar cambios de configuración solo en el primario.
• Verificar el estado de HA después de cambios en switches, VLANs o interfaces.
• Incluir registros de ambos nodos.
• Usar Sophos Central Firewall Reporting o Syslog para análisis más largos.
• Realizar intercambio o reimagen de un nodo solo con desactivación planificada de HA y reconfiguración.

No hacer

• No agrupar modelos diferentes.
• No planificar modelos Wi-Fi XGS para HA.
• No dejar WAN celular activa en HA.
• No establecer puertos no cableados como puertos monitoreados.
• No usar un VLAN o ruta de switch inestable como enlace HA.
• No realizar servicios productivos a través del enlace HA.
• No considerar Active-Active como una simple duplicación del rendimiento.
• No esperar o planificar cambios en el firewall auxiliar.
• No realizar restauraciones sin una ventana de mantenimiento.

Preguntas frecuentes