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 la dirección IP de origen para distribuir las conexiones: la Primary suele procesar las conexiones TCP de direcciones IP de origen pares y las impares se envían a la Auxiliary. Se distribuyen las conexiones TCP reenviadas o traducidas, incluidas las que pasan por interfaces VLAN. Después de procesar una conexión, la Auxiliary envía los paquetes directamente al destino y no de vuelta a través de la Primary. Este método par-impar es fijo y no puede cambiarse. 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. Esta propiedad se mantiene con independencia de que el nodo esté actualmente Active o Passive.
• Preferred primary: Dispositivo preferido que debe volver a ser Primary después de un failover cuando esté disponible de forma estable.

En el modo Active-Passive, WebAdmin en la Auxiliary no muestra Live users, DHCP leases ni conexiones IPsec activas. Es un comportamiento previsto y no demuestra que la sincronización haya fallado. La Primary actualmente activa es la referencia para estos datos de ejecución.

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

Si un solo Node se inicia en modo Failsafe, primero se documentan su función y el estado del peer. Comprobar una Sophos Firewall en modo Failsafe muestra el comando de diagnóstico de solo lectura y explica por qué no deben reiniciarse ambos Nodes sin coordinación ni desactivarse HA por una mera sospecha.

Los heartbeats del Dedicated HA Link son solicitudes VRRP. De forma predeterminada, Sophos Firewall envía un heartbeat cada 250 milisegundos. El peer solo se considera inaccesible después de perder 16 heartbeats consecutivos. En cambio, con Monitored Ports basta el fallo de un único puerto para considerar que el dispositivo no está disponible y activar el failover.

Después del failover, WebAdmin en la anterior Auxiliary Firewall muestra la configuración de la Primary. Las sesiones activas tienen límites diferentes:

Cuando vuelve la Initial Primary, permanece como Auxiliary si no se ha seleccionado Preferred primary. Si es la Preferred primary, SFOS primero sincroniza los servicios y luego revierte automáticamente. Durante este proceso se reinicia el dispositivo que había estado funcionando de forma independiente. Por ello, este retorno debe planificarse en una ventana de mantenimiento, aunque el clúster normalmente siga disponible durante la operación.

Servicios compatibles y restringidos

Sophos HA admite la mayoría de los servicios de firewall, pero sus límites operativos difieren considerablemente:

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 y modelo de módulo Flexi Port.
• 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.

Importante: Los módulos Flexi Port no son intercambiables en caliente. Para añadirlos, apague de forma controlada ambos firewalls, instale el mismo modelo de módulo en los dos dispositivos y reinicie ambos. A continuación, configure los nuevos Flexi Ports únicamente en el Primary actual, en Network > Interfaces. SFOS sincroniza esta configuración de puertos con el Auxiliary. No modifique solo un nodo mientras el clúster esté en funcionamiento.

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.

Si el clúster utiliza la dirección MAC virtual generada por SFOS, la plataforma de virtualización debe aceptar cambios de MAC. En VMware ESXi, establezca MAC Address Changes y Forged Transmits en Accept en el vSwitch o grupo de puertos; los grupos deben heredar los valores del vSwitch o configurarse de forma equivalente. En Hyper-V, active Enable MAC address spoofing en todos los adaptadores de red virtuales de ambos firewalls excepto el adaptador del Dedicated HA Link. Como alternativa, seleccione Use host or hypervisor-assigned MAC address en HA; estos cambios de plataforma no serán necesarios.

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.

Gateway, Bridge y Discover/TAP

HA está disponible en los modos gateway y bridge. El modo Discover o TAP solo admite Active-Passive. Si al menos un nodo funciona en modo discover, no puede crearse un clúster Active-Active. Una interfaz TAP activa también impide configurar Active-Passive. Desactive la interfaz TAP en ambos firewalls mediante la CLI, establezca HA y vuelva a activar TAP individualmente en cada nodo. TAP permanece activo también en la Auxiliary pasiva.

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, pero termina cuando el dispositivo alcanza el fin de vida. En appliances cloud, virtuales y de software la licencia Base Firewall no caduca, pero debe estar presente para HA.
• 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: Advance Hardware Replacement requiere Enhanced Plus Support en la Primary de un clúster de hardware Active-Passive. En Active-Active, cada dispositivo necesita Enhanced Support o Enhanced Plus Support.

Administrar el par HA en Sophos Central

Un par HA ya creado se administra en Sophos Central como un único par, no como dos firewalls independientes. Ambos nodos necesitan la misma versión de firmware y, para Central Management, acceso funcional a Internet mediante IPv4 y la suscripción adecuada. El claiming y la sincronización de licencias por sí solos no activan la administración.

Si dos firewalls ya administrados individualmente en Sophos Central se unen en un par HA, Sophos recomienda deregistrar ambos primero. Establezca HA localmente, registre de nuevo el par completo para Central Management y muévalo a otro grupo de Central si es necesario.

En la Primary actual, ir a System > Sophos Central y seleccionar Register both HA devices. Después, activar Central Management y, en Sophos Central bajo My Products > Firewall Management > Firewalls, abrir Approval Pending para la Primary y confirmar accept-services. Tras unos minutos, el par debería aparecer una sola vez con el icono HA; los cambios desde Sophos Central se aplican entonces a ambos firewalls.

El estado de Central no sustituye la validación local. Después del registro, comprobar localmente los roles HA, la sincronización, el estado de las licencias y una comparación de configuración inocua. Si aparecen dos entradas independientes o permanece Approval Pending, no deregistrar ninguno de los firewalls como medida preventiva. Primero comparar números de serie, tenant de Central, ruta IPv4 y estado HA local.

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.

Licencia en el firewall equivocado: Si las suscripciones se asignaron por error al Auxiliary en lugar de al Initial Primary, la sincronización no es suficiente. Desactive HA de forma planificada en el Primary actual, transfiera las suscripciones del Auxiliary al Primary en Sophos Central y vuelva a configurar el clúster HA. La misma transferencia de licencias se aplica a un RMA o a la sustitución de modelos antiguos. Como los modelos HA deben ser idénticos, al cambiar de modelo deben sustituirse ambos dispositivos.

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.

En Active-Passive, las interfaces de producción pueden usar DHCP, DHCP Prefix Delegation o PPPoE, pero el Dedicated HA Link y ambos puertos de administración requieren direcciones estáticas. En Active-Active, todas las interfaces deben tener direcciones estáticas.

Configure las interfaces breakout en la Primary. Reinicie primero la Primary para aplicar el cambio y después la Auxiliary. Si la Primary no tiene la configuración breakout correspondiente, la sincronización elimina una configuración breakout existente solo en la Auxiliary.

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. No se puede reutilizar para HSRP porque los mensajes hello de HSRP no atraviesan el Dedicated HA Link. 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. Ambos nodos utilizan la misma red de administración. Sin embargo, SFOS sincroniza la configuración normal de la interfaz, incluida la IP de PortMGMT, desde la Primary hacia la Auxiliary, por lo que esta IP de interfaz no puede ser diferente en cada nodo. El ajuste separado de Peer Administration asigna a la Auxiliary una IP de administración adicional y distinta en la misma subred. QuickHA utiliza automáticamente la interfaz de la sesión WebAdmin actual. Una vez establecido HA, solo se puede acceder a la Auxiliary mediante esta dirección Peer Admin desde la subred correspondiente.

La dirección predeterminada de los puertos normales es 172.16.16.16; el PortMGMT dedicado de los appliances grandes utiliza 10.0.1.1. La Primary es accesible desde cualquier zona donde HTTPS esté permitido bajo Administration > Device access. Para acceder a WebAdmin en la Auxiliary, el endpoint de administración debe estar en la misma subred que su puerto de administración.

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.

Puertos de alta velocidad: Para puertos de 25, 50 y 100 GbE de XGS 7500/8500 Series, seleccione en ambos lados el mismo Link mode con velocidad y dúplex coincidentes bajo Network > Interfaces > Advanced settings. Después use Show recommended settings > Load recommended configuration para negotiation y Forward Error Correction (FEC). Si las recomendaciones están vacías, desactive Auto-negotiation para Media Type y FEC. En otros puertos use Automatic o valores idénticos de velocidad y dúplex, y conserve MTU y MSS predeterminados. Si QuickHA selecciona una interfaz unbound, SFOS restablece sus Advanced settings; vuelva a comprobarlos después de establecer HA.

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.
• Los nodos HA separados geográficamente solo son razonables sobre una red Layer 2 de baja latencia en el mismo dominio de broadcast. El Dedicated HA Link permanece en la misma subred IP; una latencia alta o pérdida de paquetes hacen que este diseño no sea adecuado.
• 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.

FIPS sigue una secuencia diferente a LINCE. El modo FIPS 140-3 se activa primero en el Primary independiente, lo que ejecuta un restablecimiento de fábrica; durante la configuración HA posterior, Sophos activa FIPS automáticamente en el Auxiliary.

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.

Entender y activar el modo LINCE en Sophos Firewall explica por qué el modo no certifica automáticamente la compilación de SFOS instalada y qué algoritmos SSH deben comprobarse antes de activarlo.

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 dispositivos QuickHA preparados siguen buscando su peer hasta encontrarlo. Por ello, pueden configurarse de antemano y conectarse más tarde en el destino. Cuando un dispositivo ha descubierto el peer y está estableciendo HA, este proceso de discovery ya no puede detenerse. La selección de interfaces, la passphrase y el peer previsto deben ser correctos antes de que ambos enlaces HA estén disponibles al mismo tiempo.

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.

Pueden seleccionarse interfaces físicas, LAGs e interfaces no vinculadas con una VLAN configurada. Una interfaz no vinculada sin VLAN no puede seleccionarse como Monitored Port.

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.

Antes de la configuración, habilitar SSH y Ping/Ping6 para la zona DMZ en ambos dispositivos desde Administration > Device access. Interactive mode selecciona inicialmente de forma automática la primera interfaz DMZ como Dedicated HA link. Si esa interfaz no está prevista para HA o tiene dependencias productivas, seleccionar antes de guardar una interfaz física, VLAN o LAG preparada que esté libre.

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. Los rangos permitidos son de 250 a 500 milisegundos para el intervalo y de 16 a 24 intentos. El valor predeterminado de 250 milisegundos y 16 intentos produce un timeout de cuatro segundos. Estos valores no pueden modificarse cuando los dispositivos tienen estado Standalone o Faulty. Después del timeout, la nueva Primary realiza comprobaciones internas antes de empezar a procesar tráfico.

Conectar una nueva Auxiliary virtual como HA spare

Para una nueva Auxiliary virtual en Active-Passive, el Setup Assistant puede usar Connect as HA spare. Active-Active o dos firewalls Virtual/Software ya existentes siguen requiriendo QuickHA o Interactive mode en ambos dispositivos.

1. En la Primary existente, permita SSH para DMZ bajo Administration > Device access y prepare Active-Passive en Interactive mode. Documente el Dedicated HA Link, la IP del peer, Peer Administration y la passphrase HA. La Primary puede mostrar Standalone hasta que se una la nueva Auxiliary.
2. Instale el nuevo firewall virtual con exactamente el mismo build de SFOS, inicie el Setup Assistant y establezca una nueva contraseña de administrador.
3. Seleccione Connect as HA spare e introduzca el número de serie de la Primary existente, la misma passphrase HA, la misma interfaz Dedicated HA Link y una IP libre con la misma máscara de subred.
4. Seleccione Apply, Continue y Finish. SFOS crea la Auxiliary, asigna un número de serie que comienza por HAAUX y configura automáticamente el Dedicated HA Link y el puerto de administración.
5. Tras unos minutos, actualice WebAdmin de la Auxiliary y vuelva a iniciar sesión. Compruebe después en la Primary los roles, la sincronización, Peer Admin, Monitored Ports y failover.

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

Comprobar los parámetros operativos de SFOS 22

SFOS 22 publica dos controles HA adicionales. Ambos se leen antes de realizar cualquier cambio:

system ha auxiliary_system_traffic_through_dedicated_link show
system ha load-balancing show

El primer control determina la ruta del tráfico de sistema enviado por la propia Auxiliary Firewall. Por defecto, todo este tráfico pasa por el Dedicated HA Link. Además de all, están disponibles none y only_dynamic_interface. Sophos no define con mayor precisión qué flujos cuentan como interfaz dinámica en el último modo. Esta opción solo se utiliza para un caso de uso confirmado en el build instalado y no como solución general de routing.

El segundo control activa o desactiva la distribución del tráfico apto entre los firewalls. No sustituye la elección del modo HA ni hace aptos para load balancing los servicios y túneles excluidos anteriormente. Los cambios se realizan individualmente en una ventana de mantenimiento y se guardan antes ambas salidas de show:

system ha auxiliary_system_traffic_through_dedicated_link [all|none|only_dynamic_interface]
system ha load-balancing [on|off]

A continuación se comprueban los roles, la sincronización, el Dedicated HA Link, las sesiones nuevas, los logs locales de cada nodo y las conexiones de sistema iniciadas por la propia Auxiliary. Para el rollback se restaura el valor observado previamente. Sophos solo documenta all como valor predeterminado del primer control; no se presupone un valor predeterminado para load balancing.

El dispositivo Initial Primary titular de la licencia se comprueba en System services > High availability. Sophos también documenta la siguiente comprobación CLI oficial en Advanced Shell:

nvram get "#li.master"

YES identifica el Initial Primary que posee las licencias del clúster; NO identifica el dispositivo configurado como Auxiliary. El comando es de solo lectura. La vista HA sigue siendo más cómoda para el control diario, pero la salida de la shell también está documentada oficialmente.

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.

La Auxiliary solo envía informes por email cuando contienen datos en ese nodo, por ejemplo actividad de email o Pattern Updates. No envía informes sin datos, como Security Dashboard o Security Audit. Por tanto, la ausencia de un email de estos tipos de informe no demuestra por sí sola que exista un fallo.

Para los eventos HA, abrir Log viewer > System por separado en cada nodo y filtrar el periodo afectado. Para un análisis detallado, abrir Diagnostics > Tools > Troubleshooting logs > Select files en ambos dispositivos, seleccionar al menos csc.log y guardar cada paquete por separado con Download. Solo la comparación de ambos nodos muestra la secuencia completa del clúster.

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.

Sincronización manual y cambio de rol forzado

La sincronización automática es el funcionamiento normal. Utilice Sync auxiliary device en la Primary o la Auxiliary solo para resolver un problema de sincronización confirmado. La Auxiliary se reinicia, realiza una sincronización completa de la base de datos y los archivos relacionados, y permanece como Auxiliary. Los logs y los informes permanecen locales en cada nodo. El firewall descarta todas las conexiones con masquerading durante el proceso, por lo que debe programarse en una ventana de mantenimiento.

En Active-Passive, fuerce la toma de control de la Auxiliary con Switch to passive device en la Primary actual o Switch to active device en la Auxiliary actual. La Primary actual se reinicia. Se trata de un cambio de rol planificado con riesgo para las sesiones, no de un simple conmutador.

Desactivar HA de forma controlada

Siempre que sea posible, desactive HA en la Primary actual bajo System services > High availability > Disable HA. El nodo utilizado determina el resultado:

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.

El rollback de firmware del par HA sigue el mismo proceso y no requiere desactivar HA previamente.

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

Crear copias de seguridad regularmente y antes de cada cambio importante. Si LINCE está activado, la copia de seguridad y el clúster de destino deben tener el mismo estado LINCE. Existen tres casos de restauración:

Si la Primary estaba registrada como gateway de Sophos ZTNA, debe añadirse de nuevo como gateway en Sophos ZTNA después de restaurar el clúster HA.

Reimage de nodos HA en Active-Passive

Un reimage interrumpe el funcionamiento y, según Sophos, estos procedimientos solo se aplican a Active-Passive. Ejecute primero system diagnostics show version-info en Device Console de ambos nodos, documente el firmware incluido el build y el Initial Primary, y guarde externamente una copia de seguridad actual.

Si el clúster utiliza Sophos Central Synchronized Security, el par HA debe eliminarse de la administración de Central antes de devolver el dispositivo mediante el proceso RMA. Después de la sustitución, el nuevo clúster HA se vuelve a registrar en Central. Esto evita conflictos de sincronización de números de serie y licencias con el dispositivo anterior que aún permanece registrado.

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. Si el nodo afectado realmente se ha reiniciado y no solo ha cambiado de rol, comprobar el reinicio inesperado específicamente para ese nodo.
• 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.

La comprobación física completa con ethtool, datos del módulo y casos especiales conocidos se explica en Seleccionar y comprobar SFP y SFP+ en Sophos Firewall.

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 · Preguntas frecuentes sobre HA