Configurar High Availability (HA) en Sophos Firewall

High Availability, o HA, conecta dos Sophos Firewalls en un clúster. En la mayoría de los entornos, Active-Passive con QuickHA es la mejor opción: un firewall procesa el tráfico y el segundo asume el servicio en caso de fallo o mantenimiento. Antes de empezar, deben coincidir los dispositivos, las compilaciones de firmware, las licencias, el cableado y el acceso de administración.

Este artículo cubre desde la selección del modo HA y la configuración hasta la prueba de failover, la operación y RMA. HA no sustituye un diseño de red correcto ni las copias de seguridad.

Elegir el modo HA y la arquitectura

En la mayoría de los entornos productivos, Active-Passive es la mejor variante HA. Un firewall procesa todo el tráfico y el segundo queda preparado para asumir el servicio durante un fallo o mantenimiento. El diseño es más sencillo, la licencia cuesta menos y el comportamiento en caso de fallo resulta más fácil de entender.

Active-Active solo es conveniente si se aceptan conscientemente sus límites. No es un balanceo de carga simétrico clásico en el que ambos firewalls ocupan una posición equivalente en toda la red. La Primary Firewall sigue recibiendo el tráfico y distribuye determinadas conexiones a la Auxiliary Firewall. No todos los servicios ni todos los tipos de tráfico se distribuyen.

Orientación rápida:

• Máxima estabilidad y operación sencilla: Active-Passive.
• Utilizar el segundo firewall sin licencias de protección separadas: Active-Passive.
• Se necesita más rendimiento para determinadas conexiones TCP: Evaluar Active-Active.
• Muchos casos de VPN, proxy, RED, NDR o situaciones especiales: Preferir Active-Passive.
• Entorno pequeño o mediano sin un problema de rendimiento claro: Active-Passive.
• Requisito de rendimiento claro y licencias adecuadas para ambos appliances: Active-Active después de probarlo.

Los dos Sophos Techvids muestran visualmente la configuración y los cambios de rol:

Qué significa High Availability

Un clúster HA de Sophos Firewall consta de dos firewalls. Los dispositivos intercambian heartbeats, estado, información de conexiones y datos de configuración a través de un enlace HA dedicado. La configuración se sincroniza desde la Primary Firewall hacia la Auxiliary Firewall.

HA protege frente a fallos habituales:

• Fallo de la Primary Firewall
• Fallo de alimentación o hardware
• Fallo de una interfaz supervisada
• Problema de software o servicio que impide operar al dispositivo
• Actualizaciones de firmware planificadas
• Cambio de rol planificado durante el mantenimiento

Sin embargo, HA no resuelve todos los problemas:

• Un conjunto de reglas incorrecto sigue siendo incorrecto en el clúster.
• El fallo de un switch compartido puede afectar a ambos firewalls simultáneamente.
• Un diseño VLAN defectuoso o un concepto de routing erróneo no se corrigen automáticamente.
• Los logs y informes no se sincronizan por completo entre ambos firewalls.
• La copia de seguridad sigue siendo obligatoria.

Antes de planificar HA deben estar claros los fundamentos de zonas, interfaces, VLANs, LAGs y bridges. Véase Planificar y configurar zonas e interfaces de Sophos Firewall.

Active-Passive o Active-Active

Active-Passive

Con Active-Passive, un firewall procesa todo el tráfico productivo. El segundo permanece pasivo y solo asume el servicio si falla el firewall activo o si un failover se activa manualmente o por mantenimiento.

Características habituales:

• La Primary Firewall procesa el tráfico.
• La Auxiliary Firewall permanece en standby.
• Las sesiones se sincronizan siempre que el servicio correspondiente lo permita.
• En appliances de hardware, solo el dispositivo titular necesita las suscripciones de protección.
• Durante un failover, la Auxiliary Firewall asume el servicio con la misma dirección MAC virtual.
• Por lo general, los dispositivos de red no necesitan volver a aprender sus vecinos.

Active-Passive suele ser la mejor opción para empresas, sucursales, centros de datos y entornos donde la estabilidad importa más que una posible mejora de rendimiento.

Active-Active

Con Active-Active, ambos firewalls procesan tráfico. Aun así, la arquitectura sigue siendo asimétrica: la Primary Firewall recibe el tráfico y decide si procesa una conexión o la reenvía a la Auxiliary Firewall.

Sophos utiliza, entre otros criterios, la dirección IP de origen para distribuir las conexiones: la Primary suele procesar conexiones TCP de direcciones IP de origen pares y las impares pueden enviarse a la Auxiliary. Se distribuyen las conexiones TCP reenviadas o traducidas. No se distribuyen el tráfico no TCP, SD-RED y tunelizado ni las conexiones de Layer 7 mediante DPI o proxy, incluidos SMTP Proxy, HTTPS, FTP escaneado y H.323. Sophos no admite balanceadores de carga externos delante del clúster para esta lógica HA.

Ambos nodos necesitan licencias adecuadas y guardan localmente los logs del tráfico que procesan. Por ello, Active-Active solo tiene sentido con un objetivo de rendimiento claro y cuando el tráfico relevante se distribuye de forma demostrable. Para obtener únicamente alta disponibilidad, Active-Passive suele ser la opción más limpia.

Roles, estado y failover

Roles del clúster HA

• Primary: Dispositivo que mantiene la configuración central del clúster. En ambos modos HA, la Primary recibe el tráfico.
• Auxiliary: Segundo dispositivo del clúster. Sincroniza la configuración desde la Primary y asume el servicio cuando es necesario.
• Initial primary: Dispositivo que se inició como Primary durante la configuración. En Active-Passive suele ser también el titular de la licencia.
• Preferred primary: Dispositivo preferido que debe volver a ser Primary después de un failover cuando esté disponible de forma estable.

Valores de estado durante la operación

• Active: El dispositivo procesa tráfico.
• Passive: El dispositivo está preparado, pero no procesa tráfico productivo en Active-Passive.
• Standalone: El dispositivo no ve al peer o HA no está completamente activo. Ambos dispositivos pueden pasar a Standalone si falla el enlace HA.
• Faulty: El dispositivo no está en condiciones adecuadas para participar con normalidad en el clúster.

Dirección MAC virtual

Sophos Firewall utiliza direcciones MAC virtuales para las interfaces productivas de un clúster HA. Solo la Primary responde a las solicitudes ARP del clúster. Durante un failover, la Auxiliary asume esta dirección MAC virtual. Esto mantiene más estable la conectividad para switches, routers y clientes porque la asignación entre IP y MAC no cambia de forma fundamental.

La Cluster ID es importante porque se utiliza para la dirección MAC virtual. Si hay varios clústeres HA en el mismo entorno Layer 2, cada uno debe usar una Cluster ID única. De lo contrario pueden producirse conflictos de MAC.

Qué se sincroniza

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

Comportamiento del failover

Varios eventos pueden activar un failover:

• Dejan de recibirse heartbeats por el enlace HA
• Fallo de un puerto supervisado
• Corte de alimentación
• Fallo de hardware
• Problema de software o servicio
• Cambio de rol planificado
• Actualización de firmware

Los heartbeats circulan por el enlace HA dedicado. De forma predeterminada se utilizan intervalos muy cortos. Si faltan varios heartbeats consecutivos, el peer se considera inaccesible. El firewall evalúa entonces el estado y ejecuta el cambio de rol.

Muchas conexiones continúan o se restablecen rápidamente durante un failover. Sin embargo, el proceso no es totalmente transparente para todas las aplicaciones. En especial, las conexiones TCP con estado, las sesiones web, las conexiones de proxy o determinados escenarios VPN pueden interrumpirse brevemente o tener que restablecerse.

Servicios compatibles y restringidos

Sophos HA admite la mayoría de los servicios de firewall, aunque algunos tienen características especiales.

• Reglas de firewall y NAT se sincronizan. En Active-Active es importante saber qué nodo procesa una conexión.
• VPN funciona en muchos escenarios HA, pero no todos los tipos de sesión cambian sin interrupción. IPsec puede asumir tráfico UDP/ICMP sin estado mejor que TCP con estado.
• Web Protection funciona en el clúster. En Active-Active pueden llegar alertas desde ambos nodos.
• Email Protection puede gestionar cuarentena y liberación por nodo, ya que cada dispositivo guarda sus propios datos del tráfico de correo 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 solo debe planificarse con Active-Passive en entornos HA.
• sFlow funciona únicamente en la Primary en entornos HA.
• Informes se generan localmente en cada dispositivo. Sophos Central Firewall Reporting es más apropiado para informes consolidados.
• Cellular WAN debe desactivarse para HA.
• Los modelos XGS Wi-Fi no admiten HA.

Si el reporting o la conservación de logs son importantes, conviene planificar pronto si se utilizará un servidor syslog externo o Sophos Central Firewall Reporting. Véase Activar Central Firewall Reporting.

Requisitos y diseño de red

Antes de la implementación deben comprobarse cuidadosamente los requisitos HA en el entorno. Pequeñas diferencias en modelos, firmware, interfaces, Cellular WAN o plataformas virtuales pueden tener consecuencias importantes.

Compatibilidad de hardware y modelos

• Modelo de appliance: Ambos firewalls deben ser el mismo modelo XGS, por ejemplo XGS 2100 con XGS 2100.
• Revisión de hardware: Pueden utilizarse revisiones de hardware distintas del mismo modelo XGS.
• Modelos XGS Wi-Fi: No compatibles. Algunos ejemplos son XGS 126w y XGS 136w.
• Flexi Port Modules: Si se utilizan módulos de expansión, ambos dispositivos deben tener el mismo número de Flexi Ports.
• Firmware: Ambos dispositivos deben ejecutar la misma versión SFOS, incluido Maintenance Release y build.
• Hardware más appliance virtual: No pueden formar una pareja HA.

SFOS 22 ya no admite hardware XG ni SG Series. Antes de migrar a SFOS 22, estos dispositivos deben sustituirse por un appliance XGS compatible o por una plataforma virtual adecuada.

Appliances virtuales y de software

Los appliances virtuales y de software también deben coincidir con precisión.

• Plataforma: Mismo tipo de appliance y plataforma SFOS.
• Hypervisor: Mismo tipo de hypervisor.
• Recursos: Mismo número de núcleos de CPU, recursos comparables y el mismo número de interfaces de red.
• Firmware: Misma versión SFOS, incluido el build.
• Direcciones MAC: En entornos virtuales, la opción de direcciones MAC asignadas por el hypervisor puede evitar la necesidad de Promiscuous Mode. Cambiar esta opción provoca tiempo de inactividad.

Deployments en la nube

Los entornos cloud tienen requisitos adicionales de plataforma. Routing, interfaces virtuales, direcciones IP, Security Groups, UDRs y mecanismos de failover específicos de la nube deben encajar con el diseño correspondiente. El enfoque HA normal de un appliance no puede trasladarse sin revisión a Azure, AWS u otras nubes.

Antes de planificar HA para Sophos Firewall en la nube, deben consultarse la documentación actual de Sophos para la plataforma y la arquitectura de red cloud.

Licencias y registro

Las licencias HA varían según la plataforma y el modo HA. Hay tres preguntas decisivas: ¿se utiliza hardware o Virtual/Software? ¿Active-Passive o Active-Active? ¿Qué dispositivo es el Initial Primary y, por tanto, el titular de la licencia del clúster? Antes de implementar, estos puntos deben compararse con el estado de las licencias, los números de serie y el modo previsto.

Puntos principales de las licencias:

• Base Firewall: HA requiere una licencia Base Firewall. Los appliances de hardware la incluyen de forma predeterminada. Los appliances Virtual/Software deben tener la licencia correspondiente.
• Hardware Active-Passive: Solo el Initial Primary necesita las suscripciones productivas. La Auxiliary Firewall recibe una copia de las suscripciones y puede procesar tráfico después de un failover.
• Hardware Active-Active: Ambos firewalls necesitan sus propias licencias compatibles. Los tipos deben coincidir, aunque las fechas de expiración pueden ser diferentes.
• Active-Passive Virtual/Software: Solo la Primary necesita las licencias requeridas, incluida Base Firewall.
• Active-Active Virtual/Software: Ambos dispositivos necesitan su propia licencia Base Firewall y las licencias de protección adicionales correspondientes.
• Registro de hardware: Ambos dispositivos deben estar registrados en Sophos Central antes de configurar HA y deben poder sincronizar sus licencias.
• Registro de Virtual/Software Active-Passive: Según Sophos, en Active-Passive Virtual/Software solo se registra la Primary.
• Sophos Central Management: Sincronizar las licencias y registrar los dispositivos no significa automáticamente que los firewalls puedan administrarse mediante Sophos Central Firewall Management. Se requiere una suscripción adicional adecuada.
• RMA y soporte: El estado de soporte es importante para el reemplazo de hardware y Advance Replacement. Para hardware Active-Passive, Sophos indica Enhanced Plus Support en la Primary como requisito relevante para Advance Hardware Replacement. En Active-Active, ambos dispositivos deben tener un estado de soporte adecuado.

El Initial Primary es especialmente importante en Active-Passive porque este dispositivo posee la licencia del clúster. La vista HA indica qué dispositivo mantiene esa licencia. Debe documentarse de forma inequívoca en el manual de operación.

Si las licencias de Active-Active no coinciden, el balanceo de carga se detiene durante un máximo de tres días. Si la diferencia continúa, el firewall desactiva HA. Durante la configuración inicial, Active-Active no se activa si las licencias no coinciden.

El Initial Primary debe sincronizar las licencias al menos una vez cada 90 días. En hardware, de lo contrario se detienen las suscripciones de protección afectadas, mientras Base Firewall y Enhanced Support permanecen activos. En Virtual/Software se desactiva la licencia Base Firewall, se deshabilita HA y quedan inactivas otras funciones de protección. Por tanto, los clústeres con licencia en línea necesitan DNS, hora del sistema correcta, routing y acceso a Internet hacia los servicios de licencias de Sophos. Los clústeres aislados utilizan en su lugar el proceso manual documentado de licencias Air-Gap.

Como mínimo, debe documentarse:

• Qué dispositivo es el Initial Primary
• Qué números de serie o appliance IDs pertenecen al clúster
• Qué licencias están activas en cada dispositivo
• Cuándo se sincronizaron las licencias por última vez
• Qué nivel de soporte está disponible para RMA o Advance Replacement
• Quién autoriza cambios de licencia, renovaciones y procesos RMA

Requisitos de red

• Enlace HA: Conexión dedicada entre ambos firewalls, idealmente directa mediante cable Ethernet.
• Zona del enlace HA: Zona DMZ con SSH habilitado para la zona.
• Direcciones IP del enlace HA: Direcciones IP estáticas en la misma subred, pero diferentes.
• Calidad del enlace HA: Alto ancho de banda, baja latencia y sin pérdida de paquetes.
• Switches: Activar RSTP en los switches conectados a puertos del firewall.
• Monitored Ports: Supervisar únicamente puertos conectados y críticos.
• Cellular WAN: Desactivar para HA.
• Peer Admin Port: Planificar por separado para mantener accesible la Auxiliary Firewall.
• Direcciones de interfaces: Active-Active requiere direcciones IP estáticas en todas las interfaces. Active-Passive permite DHCP o PPPoE, pero estas conexiones no disponen de conmutación por error de sesiones.

El enlace HA no transporta tráfico normal de clientes o servidores. Solo se utiliza para heartbeats, estado, sincronización de sesiones, sincronización de configuración y distribución Active-Active. Aun así, es extremadamente crítico. Si falla, ambos firewalls pueden creer que son Primary. Debe evitarse este escenario de split-brain.

El Peer Admin Port proporciona un acceso operativo independiente a la Auxiliary Firewall. Los puertos de administración de ambos dispositivos deben estar en la misma subred, pero usar direcciones IP distintas. QuickHA utiliza automáticamente la interfaz por la que está conectada la sesión actual de WebAdmin. Una vez establecido HA, solo se puede acceder a la Auxiliary mediante la dirección Peer Admin desde una red adecuada.

Puertos e interfaces

• Dedicated HA link: Transporta heartbeats, estado y sincronización de configuración y sesiones. Conectarlo directamente o mediante un switch muy fiable. No usarlo para tráfico productivo.
• Monitored ports: Supervisan enlaces productivos críticos. Supervisar WAN y uplinks importantes de DMZ o core, pero no seleccionar puertos sin uso.
• Peer Admin Port: Permite acceder al WebAdmin de la Auxiliary. Planificarlo y documentarlo por separado; el cliente debe estar en la subred adecuada.
• Interfaces productivas: Cablear LAN, WAN, DMZ, VLANs y LAGs de forma idéntica en ambos firewalls y diseñarlas de manera equivalente.

Como Dedicated HA link pueden utilizarse interfaces físicas, VLANs o LAGs. No pueden utilizarse interfaces Bridge ni direcciones Alias IP. QuickHA puede combinar hasta cuatro interfaces físicas no vinculadas en un HA redundant link; en un LAG existente, las parent interfaces deben estar configuradas de forma idéntica en ambos appliances.

Importante: El Dedicated HA link y un Monitored Port no pueden ser la misma interfaz. Si se elige como enlace HA una interfaz que ya tiene configuración productiva, el firewall puede modificar o eliminar configuraciones dependientes. Por ello, el enlace HA debe estar libre y documentado previamente.

Diseño de red

Ambos firewalls deben poder asumir la misma posición de red durante un fallo. Interfaces productivas, VLAN trunks, LAGs, switchports y conexiones del proveedor deben cablearse de forma equivalente en ambos lados. La redundancia WAN, SD-WAN y el failover del proveedor siguen siendo tareas separadas; HA no las sustituye.

• Conectar el Dedicated HA link de la forma más directa posible. Si pasa por switches, la ruta debe ser estable, con baja latencia y sin pérdida de paquetes.
• Activar RSTP en los switches participantes y configurar VLANs, trunks y LAGs de forma idéntica en ambos lados.
• Supervisar solo uplinks WAN, core o DMZ conectados permanentemente. Un Monitored Port desconectado de forma intencionada activaría un failover.
• VLANs y LAGs son compatibles, pero deben utilizar las mismas parent interfaces en ambos nodos. Bridge Mode funciona, aunque es más complejo de diagnosticar que Gateway Mode.
• Probar por separado los escenarios VPN, RED y remotos, ya que no todas las sesiones se transfieren de forma transparente.
• Restringir conscientemente el acceso de administración y Device Access. Véase Proteger el acceso a Sophos Firewall: configurar correctamente Device Access.

En Active-Active también debe estar claro qué cuello de botella resolverá el tráfico apto para la distribución TCP. Si las licencias, los servicios y el resolución de problemas de ambos nodos no están definidos, Active-Passive sigue siendo la mejor opción.

Advertencia: En una situación de split-brain, ambos firewalls se consideran responsables. Esto puede provocar el uso duplicado de IP y MAC y una interrupción de producción. Si falla el enlace HA, primero debe decidirse qué nodo seguirá activo y apagar el otro de forma controlada o desconectarlo de la red productiva.

Preparar la configuración

No conviene improvisar en la red productiva antes de configurar HA. Esta preparación ahorra mucho tiempo posteriormente.

Preparar ambos firewalls

• Instalar en ambos firewalls la misma versión SFOS, incluido el build.
• Comprobar el estado de licencias y registro.
• Desactivar Cellular WAN.
• Confirmar que los modelos son compatibles.
• Comprobar la configuración de Flexi Ports.
• Documentar interfaces y switchports.
• Seleccionar el puerto del enlace HA.
• Conectar directamente el enlace HA o comprobar la ruta por switches.
• Planificar la zona DMZ y el acceso SSH para el enlace HA.
• Documentar el acceso administrativo a ambos dispositivos.
• Crear una copia de seguridad de la configuración existente.
• Si se necesita LINCE, igualar el modo en ambos dispositivos antes de activar HA.

Las copias de seguridad no son opcionales con HA. Debe existir una copia antes de la configuración, de las actualizaciones de firmware y de cambios importantes en interfaces. Véase Crear o restaurar una copia de seguridad de Sophos Firewall.

Antes de seleccionar Initiate HA, comprobar además:

• Admin Ports en la misma subred, pero con direcciones IP diferentes: De lo contrario, HA no puede establecerse correctamente o la Auxiliary no será accesible después.
• Dedicated HA link sin dependencias productivas: HA puede modificar las direcciones IP de interfaces y su configuración dependiente.
• Monitored Ports conectados en ambos dispositivos: Un Monitored Port desconectado puede impedir la formación del clúster o activar un failover inmediato.
• Cluster ID única: Varios clústeres HA en la misma área Layer 2 requieren direcciones MAC virtuales diferentes.
• Copia de seguridad, SSMK y firmware build documentados: El clúster debe poder reproducirse durante una restauración, RMA o reimage.

Definir LINCE antes de HA

Desde SFOS 21.5 MR1, LINCE no puede activarse ni desactivarse después de crear un clúster HA. Si se necesita la certificación, ejecutar el siguiente comando en Device Console en ambos firewalls todavía independientes.

Advertencia: Antes, asegurarse de disponer de WebAdmin o de la consola local como vía de administración alternativa. El comando activa LINCE, reinicia el servicio SSH y desconecta las sesiones SSH existentes.

system certification lince enable

Después, comprobar el estado LINCE en ambos dispositivos antes de crear HA. Durante una restauración, la copia de seguridad y el clúster de destino deben tener el mismo estado LINCE.

QuickHA o Interactive mode

• QuickHA: Caso estándar. Rápido, robusto y suficiente para la mayoría de las configuraciones Active-Passive y Active-Active.
• Interactive mode: Útil cuando Admin Ports, direcciones del enlace HA, Cluster ID, Monitored Ports y valores detallados deben definirse antes de crear el clúster.

QuickHA solicita inicialmente solo el rol, el nombre del nodo, la passphrase y el Dedicated HA link. La passphrase debe tener entre 10 y 20 caracteres e incluir al menos una mayúscula, una minúscula, un número y un carácter especial. Se utiliza una sola vez para generar las claves SSH y luego se elimina. Después de sustituir un dispositivo, HA debe desactivarse y configurarse de nuevo.

Los pasos siguientes se basan en la configuración HA oficial de Sophos, pero están redactados como lista de comprobación práctica para administradores. En cambios productivos no basta con recorrer el asistente: deben documentarse previamente roles, enlace HA, acceso administrativo, copia de seguridad, estado de licencias y reversión.

Configurar HA

Active-Passive con QuickHA

1. Preparar la Primary Firewall

1. Iniciar sesión en WebAdmin en el firewall que será Primary.
2. Ir a System services > High availability.
3. Seleccionar Primary (active-passive) como modo.
4. Utilizar QuickHA.
5. Asignar opcionalmente un nombre de nodo, por ejemplo FW01.
6. Definir una passphrase HA de 10 a 20 caracteres con mayúscula, minúscula, número y carácter especial.
7. Guardar temporalmente la passphrase de forma segura, ya que se necesitará inmediatamente en la Auxiliary Firewall.
8. Seleccionar el Dedicated HA link.
9. Seleccionar Initiate HA.

Notas:

• Si QuickHA utiliza una interfaz no vinculada, Sophos le asigna la zona DMZ y, de forma predeterminada, 169.254.192.1. SSH se habilita automáticamente para la zona.
• El firewall elimina la configuración dependiente de la interfaz elegida como enlace HA. Por ello, debe estar libre de dependencias productivas.

2. Preparar la Auxiliary Firewall

1. Iniciar sesión en el firewall que será Auxiliary.
2. Ir a System services > High availability.
3. Seleccionar Auxiliary como rol.
4. Utilizar QuickHA.
5. Asignar opcionalmente un nombre de nodo, por ejemplo FW02.
6. Introducir la misma passphrase HA.
7. Seleccionar el mismo puerto de enlace HA que en la Primary.
8. Seleccionar Initiate HA.

Una vez creado el clúster, la Primary Firewall sincroniza la configuración con la Auxiliary Firewall. Se sobrescriben muchos ajustes locales de la Auxiliary. Por ello, antes de configurar HA no debe configurarse en paralelo como firewall productivo independiente.

3. Comprobar ajustes avanzados

Después de crear el clúster deben comprobarse los siguientes puntos:

• Estado HA de ambos nodos
• Rol y estado en la esquina superior derecha de WebAdmin
• Dedicated HA link
• Monitored Ports
• Peer Admin Port
• Preferred primary
• Keepalive interval y Attempts
• Titular de la licencia en Active-Passive
• Registro en Sophos Central, si se utiliza

4. Definir Monitored Ports

Monitored Ports determinan si el fallo de una interfaz activa un failover. Candidatos habituales:

• Uplink WAN
• Uplink LAN core
• Uplinks importantes de DMZ o servidores

No deben supervisarse puertos que se desconectan intencionadamente, no están cableados o solo se usan en escenarios opcionales. Un Monitored Port seleccionado incorrectamente es una causa frecuente de failovers inesperados o de un clúster que no arranca.

Active-Active con QuickHA

Active-Active se configura de forma similar, pero con un objetivo diferente. Ambos firewalls deben disponer previamente de licencias adecuadas.

El proceso es igual que en Active-Passive, pero en FW01 se selecciona Primary (active-active). Ambos dispositivos deben estar registrados, ejecutar el mismo SFOS build y tener tipos de licencia compatibles; todas las interfaces necesitan direcciones IP estáticas. La supervisión y la resolución de problemas deben cubrir ambos nodos, y el tráfico relevante debe beneficiarse de la distribución TCP descrita anteriormente.

Probar después de la configuración

En Active-Active debe probarse algo más que el estado HA:

• ¿Se distribuyen las conexiones entre ambos nodos?
• ¿Se ven logs en ambos dispositivos?
• ¿Funcionan las conexiones VPN después de un cambio de rol?
• ¿Funcionan Web Protection, IPS, Application Control y las funciones de seguridad relevantes?
• ¿Hay aplicaciones afectadas por el comportamiento asimétrico?
• ¿Se generan los informes y las alertas esperados?

Interactive mode

Interactive mode es útil cuando la lógica automática de QuickHA no ofrece suficiente control.

Motivos habituales:

• Deben utilizarse direcciones IP fijas para el enlace HA
• El Peer Admin Port debe definirse con precisión
• La Cluster ID debe establecerse conscientemente
• Existen varios clústeres HA en el mismo entorno Layer 2
• Los appliances virtuales requieren opciones MAC específicas
• Se necesita un despliegue muy controlado

En Interactive mode se configura primero la Auxiliary y después la Primary. Así se evita que expire la detección del peer en la Primary mientras todavía se prepara el segundo nodo.

1. Configurar la Auxiliary

1. En FW02, ir a System services > High availability.
2. Seleccionar Initial device role > Auxiliary y HA configuration mode > Interactive mode.
3. Definir el nombre del nodo y una passphrase que cumpla las reglas anteriores.
4. Seleccionar el puerto DMZ libre para el Dedicated HA link. El firewall elimina la configuración dependiente existente de esta interfaz.
5. Guardar y esperar la confirmación de que se ha aplicado la configuración de la Auxiliary.

2. Configurar la Primary

1. En FW01, seleccionar Primary (active-passive) o Primary (active-active) e Interactive mode.
2. Definir una Cluster ID única y el nombre del nodo.
3. Introducir la passphrase de FW02.
4. Indicar el mismo Dedicated HA link y la dirección IP estática del enlace HA de la Auxiliary.
5. Seleccionar los Monitored ports críticos.
6. En Peer administration settings, indicar la interfaz de administración y una dirección IP propia para FW02.
7. En appliances virtuales, seleccionar si es necesario la dirección MAC asignada por el host o el hypervisor. Un cambio posterior provoca tiempo de inactividad.
8. Definir Preferred primary y seleccionar Initiate HA.

Después de crear el clúster, modificar los valores keepalive solo por un motivo documentado. De forma predeterminada, el firewall envía un heartbeat cada 250 milisegundos y considera el peer inaccesible después de 16 heartbeats ausentes.

Validar el clúster

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

Comprobación en WebAdmin

1. Iniciar sesión en la Primary Firewall.
2. Comprobar el estado HA en la esquina superior derecha.
3. Ir a System services > High availability.
4. Comprobar roles, estado, números de serie y modo.
5. Confirmar que el clúster está sincronizado.
6. En Active-Passive, comprobar qué dispositivo mantiene la licencia del clúster.

Comprobación por CLI

En Device Console, el siguiente comando de solo lectura muestra roles, estado y sincronización del clúster. No cambia la configuración:

system ha show details

El dispositivo Initial Primary titular de la licencia debe comprobarse principalmente en System services > High availability. En un caso de soporte documentado, el siguiente valor interno de solo lectura en Advanced Shell puede aportar información adicional:

nvram get "#li.master"

YES suele identificar el Initial Primary y NO la Auxiliary. Sophos no documenta este comando interno de Advanced Shell como interfaz administrativa normal, por lo que la vista HA sigue siendo la referencia.

Si aún no está preparado el acceso shell, véase Conectar con Sophos Firewall mediante SSH.

Prueba funcional

• Probar el acceso a Internet desde un cliente LAN.
• Probar el acceso a servidores internos.
• Probar VPN.
• Probar escenarios DNAT o WAF.
• Probar DNS y DHCP si el firewall ofrece estos servicios.
• Comprobar los logs en Log Viewer.
• Probar un cambio de rol HA durante una ventana de mantenimiento.
• Documentar después los roles, el estado y el comportamiento de las sesiones.

Operación y mantenimiento

Supervisión continua

Supervisar el estado HA y de roles, Dedicated HA link, Monitored Ports, licencias, firmware, CPU, RAM, disco y servicios centrales. Enviar alertas a Sophos Central, por email o a la plataforma de supervisión existente.

Para cuestiones de disco y hardware, considerar ambos nodos por separado. Los informes locales, los archivos de log y el estado del SSD pueden ser distintos. Véanse Comprobar el almacenamiento de Sophos Firewall y gestionar informes y Comprobar el estado del SSD de Sophos Firewall con SMART.

Logs y informes

Cada nodo escribe logs del tráfico que procesa. En Active-Active deben comprobarse ambos dispositivos. Sophos Central Firewall Reporting o syslog son adecuados para un análisis conjunto. Los archivos locales se explican en Resolución de problemas de Sophos Firewall: servicios y logs.

Runbook para la operación HA

Documentar como mínimo en el runbook de operación:

• Número de serie, ubicación, posición en rack y rol de ambos appliances.
• Dedicated HA link, Peer Admin Port, Cluster ID y Monitored Ports.
• Preferred primary y comportamiento esperado después de un failover.
• Titular de la licencia, estado de soporte y vía de contacto para RMA.
• Proceso y responsabilidad para actualizaciones de firmware, copia de seguridad, reimage, sustitución de hardware, logs y casos de soporte.

Si WebAdmin no responde solo en un nodo, no significa automáticamente que todo el clúster HA esté defectuoso. Primero debe comprobarse si basta con reiniciar la GUI de WebAdmin o realizar un reinicio controlado de servicios antes de activar failover o reinicio.

Cambios en el clúster

Modificar reglas, interfaces y policies únicamente en la Primary. Antes de cambiar interfaces, VLANs, LAGs, zonas, routing, NAT, VPN, Device Access o SD-WAN:

• Crear una copia de seguridad.
• Definir una ventana de mantenimiento.
• Comprobar el estado HA.
• Actualizar la documentación.
• Definir una vía de reversión.
• Probar después la sincronización y el tráfico.

Actualizaciones de firmware y copias de seguridad

Actualizaciones de firmware en entornos HA

Las actualizaciones de firmware se inician en la Primary Firewall. Los dispositivos se actualizan de forma sucesiva y el clúster puede cambiar de rol durante el proceso.

Proceso habitual:

1. Iniciar la actualización en la Primary Firewall.
2. Se actualiza la Auxiliary Firewall.
3. La Auxiliary Firewall se reinicia y asume temporalmente el servicio.
4. Se actualiza la Primary anterior.
5. La Primary anterior se reinicia.
6. Si Preferred primary está activado, puede producirse el retorno al dispositivo preferido.

Las actualizaciones de firmware deben realizarse en una ventana de mantenimiento. Aunque el proceso está diseñado para minimizar el tiempo de inactividad, algunas sesiones, conexiones VPN o aplicaciones especiales pueden reaccionar brevemente.

Véase Actualización de firmware de Sophos Firewall: preparación y buenas prácticas.

Pattern Updates

Pattern Updates se instalan en la Primary y se sincronizan automáticamente con la Auxiliary. Esto también se aplica a entornos donde las actualizaciones se controlan o instalan sin conexión.

En un entorno HA aislado, antes de cada Pattern Update o actualización de licencia manual debe quedar claro qué nodo es el Initial Primary y cuál es actualmente Primary. El proceso Air-Gap se describe en Operar licencias Air-Gap y Pattern Updates de Sophos Firewall.

Copia de seguridad y restauración

Las copias de seguridad y la restauración tienen particularidades en entornos HA:

• Crear copias de seguridad regularmente y antes de cada cambio importante.
• Realizar la restauración en la Primary Firewall actual.
• Después de la restauración, ambos firewalls se eliminan del registro de Sophos Central y deben registrarse de nuevo.
• La restauración provoca reinicio y tiempo de inactividad, no un failover normal.
• Restaurar en un clúster HA una copia de seguridad sin configuración HA desactiva HA, que debe reconstruirse.
• Si LINCE está activado, la copia de seguridad y el clúster de destino deben tener el mismo estado LINCE.

Sustituir la Auxiliary después de RMA

La sustitución o el reimage de un nodo provoca una interrupción planificada. Los siguientes procesos se aplican a Active-Passive; para Active-Active debe planificarse el procedimiento concreto con Sophos Support.

1. Comprobar que el modelo y la revisión de hardware del dispositivo de sustitución son adecuados e instalar exactamente el mismo firmware build que en la Primary sana.
2. Registrar el dispositivo de sustitución en Sophos Central y transferir la licencia del dispositivo Auxiliary defectuoso.
3. Cambiar los cables del dispositivo defectuoso al de sustitución.
4. En la Primary sana, desactivar HA en System services > High availability.
5. En Advanced Shell, comprobar si msync se ha detenido:

service -S | grep msync

Se espera UNTOUCHED o STOPPED. El comando no modifica nada; otro estado significa que HA todavía no debe reconstruirse. Después, volver a configurar la Primary sana como Primary y el dispositivo de sustitución como Auxiliary.

Sustituir la Primary después de RMA

1. Descargar una copia de seguridad actual de la Auxiliary sana y eliminar el dispositivo del registro de Sophos Central.
2. Instalar en el dispositivo de sustitución el mismo firmware build, registrarlo en Sophos Central y transferir la licencia de la Primary defectuosa.
3. Restaurar la copia de seguridad en el dispositivo de sustitución.
4. Cambiar los cables de la Auxiliary sana al dispositivo de sustitución. Desde ese momento, el dispositivo de sustitución procesa el tráfico como firewall independiente.
5. Restablecer la Auxiliary anterior a Factory Reset, registrarla de nuevo en Sophos Central y conectar los cables previstos.
6. Reconstruir HA con el dispositivo de sustitución como Primary y el dispositivo restablecido como Auxiliary.

Advertencia: Copia de seguridad/restauración, Factory Reset y los cambios de cableado provocan tiempo de inactividad. Antes de empezar deben documentarse números de serie, Initial Primary, firmware build, transferencia de licencia, estado de Central y vía de reversión.

Para la reinstalación técnica, véase Reinstalar Sophos Firewall OS: reimage con una unidad USB. Si hay un defecto de hardware o un proceso RMA, también debe planificarse Preparar correctamente un defecto de hardware y RMA de Sophos.

Resolución de problemas

En fallos complejos debe trabajarse metódicamente: comprobar primero estado, enlace HA, Monitored Ports, versión de firmware y estado de licencias; investigar después los casos especiales o las indicaciones del fabricante. Así queda claro si el problema pertenece realmente a HA o lo causan licencias, una interfaz, firmware o supervisión.

Logs y ubicaciones de diagnóstico importantes

• Estado HA: System services > High availability.
• Event Logs: Log viewer > System.
• Troubleshooting Logs: Monitor & Analyze > Logs > Troubleshooting logs o mediante SSH en /log.
• Detalles HA por CLI: Véase la única comprobación CLI en Validar el clúster.
• Problemas de interfaces: show network interfaces, ifconfig, dmesg en los casos de diagnóstico adecuados.
• Titular de la licencia: System services > High availability.

Los siguientes archivos son especialmente útiles para un diagnóstico inicial:

• ha.log: Errores de creación, creación correcta de HA y cambios de estado.
• ha_pair.log: Detección del peer en QuickHA.
• ha_tunnel.log: Túnel SSH por el Dedicated HA link.
• msync.log: Sincronización de la configuración HA.
• ctsyncd.log: Sincronización de sesiones Conntrack.
• filesync.log: Sincronización de archivos relacionada con servicios, por ejemplo para rutas dinámicas o DHCP.

Cada nodo almacena solo logs y informes del tráfico que procesa. Para acceder a la Auxiliary, iniciar sesión mediante su dirección Peer Admin o consultar los archivos de log por SSH en ese nodo.

Para análisis más profundos, véase Resolución de problemas CLI en Sophos Firewall: comandos importantes.

Síntomas HA habituales

• El clúster no se forma; la versión o el build de firmware son diferentes: Comprobar la versión en ambos dispositivos e instalar la misma versión SFOS en ambos firewalls.
• El clúster no se forma; el modelo o appliance no coincide: Comprobar modelo y número de serie. Para HA de hardware, utilizar únicamente modelos XGS idénticos y compatibles.
• HA could not be enabled: Es posible que el Dedicated HA link no esté conectado o que el peer no sea accesible. Comprobar estado del puerto, cable, switch y ping a la IP del enlace HA; después estabilizar cableado o enlace HA.
• Enlace HA down: El cable, switchport, VLAN o LAG puede estar defectuoso. Comprobar estado de interfaz, speed/duplex, VLAN trunk y miembros LAG.
• Ambos dispositivos pasan a Standalone: El enlace HA ha fallado y existe riesgo de split-brain. Comprobar la conexión física y la ruta por switches, apagar un dispositivo de forma controlada, reparar el enlace HA y reiniciarlo después.
• WebAdmin de la Auxiliary no accesible: Peer Admin Port, subred, ruta o Device Access no coinciden. Comprobar la IP del Admin Port y el acceso desde la red de administración.
• Validation failed for HA interface IP: Los Admin Ports o las direcciones del enlace HA no están en la subred prevista. Comprobar direcciones IP y /log/syslog.log, y corregir el direccionamiento.
• Failover inesperado: Con frecuencia ha fallado un Monitored Port o se ha seleccionado incorrectamente. Comprobar Monitored Ports y estado del switch; supervisar solo puertos realmente críticos y estables.
• El failover no se produce: Probablemente no se supervisa el puerto relevante. Añadir como Monitored Ports los puertos WAN, core o DMZ críticos.
• Active-Active no distribuye como se esperaba: Es posible que el tipo de tráfico no se balancee. Comprobar tipo de conexión, protocolo y logs de ambos nodos; si el beneficio no está claro, utilizar Active-Passive o adaptar el diseño.
• Parece que faltan logs: El tráfico puede haber sido procesado por el otro nodo o el registro puede estar desactivado. Comprobar ambos nodos y Log Viewer, habilitar registro en las reglas y utilizar Central Reporting o syslog.
• Los informes son diferentes: Los informes locales dependen del nodo. Comparar informes de ambos dispositivos o utilizar Sophos Central Firewall Reporting.
• Problema de licencia en Active-Active: Los tipos de licencia pueden no coincidir. Comprobar Licensing en ambos firewalls y alinear las licencias.
• Problemas después de actualizar firmware: Es posible que un nodo no se haya actualizado correctamente o que el clúster no esté sincronizado. Comprobar estado HA, versiones y logs; utilizar una ventana de mantenimiento en clústeres productivos e involucrar a Sophos Support.
• El enlace HA Flexi Port no funciona: Speed/duplex o auto-negotiation pueden no coincidir. Comprobar Interface Advanced settings en ambos dispositivos y configurar ambos lados de forma idéntica o usar un puerto fijo.

Procedimiento durante un fallo del enlace HA

Si falla el enlace HA dedicado, debe procederse con cuidado. Los firewalls dejan de verse entre sí. En el peor caso, ambos dispositivos envían ARP/GARP e intentan reclamar la MAC del clúster.

Procedimiento seguro:

1. Estabilizar el estado de la red.
2. Decidir qué dispositivo debe permanecer activo.
3. Apagar el otro dispositivo de forma controlada o desconectarlo de la red productiva.
4. Reparar el cable, switchport, VLAN o LAG del enlace HA.
5. Reiniciar el dispositivo.
6. Comprobar el estado HA.
7. Comprobar logs y roles.

Comandos CLI adicionales

Además de la consulta del estado HA en Validar el clúster, el siguiente comando de solo lectura en Device Console muestra

show network interfaces

el estado de interfaces y enlaces. Se esperan estados UP para el Dedicated HA link y los Monitored Ports conectados.

Para fluctuaciones del enlace, cambiar mediante Device Management > Advanced Shell a la shell y sustituir PortE por el nombre real de la interfaz:

dmesg | grep PortE

La salida filtra los mensajes del kernel para esa interfaz. Mensajes repetidos de link-up/link-down indican problemas de cable, transceiver, puerto o negociación. El comando no modifica nada, pero dmesg solo contiene el buffer actual del kernel y no sustituye un análisis de logs a largo plazo.

Antes de una intervención más profunda, guardar primero las salidas y los timestamps. Los comandos se comprobaron con la documentación actual de Sophos, pero no se ejecutaron en el hardware concreto del cliente.

Checklist de puesta en producción

• Active-Passive o Active-Active elegido con una justificación documentada.
• Modelos, Flexi Ports, SFOS build, estado LINCE, registro y licencias comprobados.
• Copia de seguridad y vía de reversión disponibles.
• Dedicated HA link libre, estable y conectado de la forma más directa posible.
• VLANs, LAGs, switchports y RSTP coherentes en ambos lados.
• Acceso Peer Admin a la Auxiliary probado.
• Solo interfaces estables y críticas seleccionadas como Monitored Ports.
• Cluster ID, Initial Primary, Preferred primary y números de serie documentados.
• WebAdmin, estado CLI y logs relevantes comprobados.
• LAN, Internet, servidores, VPN, DNAT/WAF, DNS y DHCP probados funcionalmente.
• Failover y retorno probados en una ventana de mantenimiento.
• Procesos de supervisión, firmware, restauración y RMA registrados en el runbook.

Preguntas frecuentes

Fuentes oficiales: Registro y licencias · LINCE en entornos HA · RMA en un clúster Active-Passive