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, compruebe que ambos dispositivos, las compilaciones de firmware, las licencias, el cableado y el acceso de administración cumplen los requisitos de HA.

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

Recomendación operativa de Avanet: 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. Es una recomendación de diseño, no un requisito de Sophos.

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. El Primary Firewall sigue recibiendo el tráfico y distribuye determinadas conexiones al 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 el Primary Firewall hacia el Auxiliary Firewall.

HA protege frente a fallos habituales:

• Fallo del 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 los informes no se sincronizan 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:

• El Primary Firewall procesa el tráfico.
• El 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.
• Si se utiliza la MAC virtual del clúster, el Auxiliary Firewall asume el servicio con la misma dirección MAC virtual durante un failover.
• En este caso, los dispositivos de red generalmente no necesitan volver a aprender la información de 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: el Primary Firewall recibe el tráfico y decide si procesa una conexión o la reenvía al Auxiliary Firewall.

Sophos utiliza la dirección IP de origen para distribuir las conexiones: el Primary procesa las conexiones TCP aptas de direcciones IP de origen pares y las impares se envían al Auxiliary. Se distribuyen el tráfico TCP reenviado y las conexiones TCP traducidas, incluidos SNAT y el tráfico de Virtual Host, también a través de interfaces VLAN. Después de procesar una conexión, el Auxiliary envía los paquetes directamente al destino y no de vuelta a través del Primary. Este método par-impar es fijo y no puede cambiarse. La compatibilidad con Layer 7 varía según el servicio: según Sophos, DPI Engine, los proxies transparentes, directos y Parent Proxies, así como el tráfico del proxy SMTP y HTTPS, admiten balanceo de carga. El FTP escaneado y H.323 no lo admiten. También quedan excluidos el tráfico no TCP, como UDP, ICMP, multicast y broadcast, SD-RED y el tráfico TCP y no TCP tunelizado, incluido VPN. Los balanceadores de carga externos no son compatibles con 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 beneficia de forma demostrable de la distribución. 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, el Primary recibe el tráfico.
• Auxiliary: Segundo dispositivo del clúster. Sincroniza la configuración desde el 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 el Auxiliary no muestra Live users, DHCP leases ni conexiones IPsec activas. Es un comportamiento previsto y no demuestra que la sincronización haya fallado. El Primary actualmente activo 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

Si se utiliza la MAC virtual del clúster, SFOS asigna direcciones MAC virtuales a las interfaces físicas, excepto al Dedicated HA Link y a los puertos de administración. El Dedicated HA Link utiliza su propia dirección MAC física. Solo el Primary responde a las solicitudes ARP del clúster. Durante un failover, el Auxiliary asume la dirección MAC virtual de cada interfaz productiva. 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 opción de MAC de interfaz descrita más abajo es otra variante; no debe suponerse que tenga el mismo comportamiento de transferencia de MAC virtual.

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 el Primary hacia el Auxiliary.
• Sesiones activas se sincronizan según el protocolo y el servicio. En Active-Active, ambos dispositivos intercambian con el peer el estado y los detalles de las sesiones activas; en cambio, la sincronización de la configuración sigue realizándose desde el Primary hacia el Auxiliary.
• Secure Storage Master Key y credenciales de WebAdmin se sincronizan.
• El Dedicated HA link y los puertos de administración están excluidos de la sincronización, según la documentación oficial de modos y roles HA. Las instrucciones oficiales sobre las direcciones de administración se contradicen, como se explica en Requisitos de red.
• Logs y informes no se sincronizan entre los dispositivos.

Comportamiento del failover

En Active-Passive, el Auxiliary asume todo el tráfico si falla el Primary. En Active-Active, en cambio, el fallo de cualquiera de los dos dispositivos activos puede hacer que el peer sano asuma el servicio. Si falla el Auxiliary, el Primary procesa todo el tráfico por sí solo; esto no implica necesariamente un cambio de rol. Si un peer deja de estar disponible, el dispositivo restante funciona como Standalone. Por tanto, este estado por sí solo no demuestra que el enlace HA haya fallado en ambos lados; comprobar los roles y la accesibilidad de ambos nodos antes de aplicar el runbook de split-brain.

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 nodo se inicia en modo Failsafe, primero se documentan su rol y el estado del peer. Comprobar un Sophos Firewall en modo Failsafe describe el procedimiento de diagnóstico seguro y explica por qué no deben reiniciarse ambos nodos sin coordinación ni debe desactivarse HA por una mera sospecha.

Los heartbeats del Dedicated HA Link son solicitudes VRRP. SFOS 22 usa por defecto 250 ms y 16 heartbeats perdidos, con un timeout de heartbeat de 4 segundos. SFOS 23 usa por defecto 100 ms y 3 intentos, con un timeout de 300 ms; los enlaces HA basados en LAG necesitan otros valores, como se explica más abajo. Estos timeouts no garantizan el tiempo de recuperación del tráfico. En cambio, con Monitored Ports basta el fallo de un único puerto para considerar que el dispositivo no está disponible y activar el failover.

Indicaciones divergentes sobre los heartbeats en SFOS 23: La descripción general del failover sigue indicando 250 ms y 16 intentos, mientras que las instrucciones detalladas de configuración de SFOS 23 indican 100 ms y 3 intentos. Los valores predeterminados citados corresponden a SFOS 23; comprobar por separado el estado real del dispositivo. Antes de realizar un cambio en System services > High availability, documentar los valores realmente configurados y la topología del enlace HA en ambos nodos. Ni la indicación anterior ni el valor predeterminado más corto de la configuración justifican modificar un clúster existente sin comprobarlo; si los valores no están claros o no cumplen el requisito de LAG, aclarar la planificación con Sophos Support.

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

Cuando vuelve el Initial Primary, permanece como Auxiliary en el clúster si no se ha seleccionado Preferred primary. Si está definido como Preferred primary, SFOS primero sincroniza los servicios y después realiza automáticamente el retorno. Durante este proceso se reinicia el dispositivo que hasta entonces había estado funcionando por sí solo. Por ello, este failback debe realizarse en una ventana de mantenimiento. Los cambios de rol y reinicios descritos no garantizan el procesamiento sin interrupciones de las conexiones existentes.

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 Fusion Firewall Reporting. Véase Activar Central Firewall Reporting.

Para la configuración, los límites de seguridad y las pruebas, utilizar Configurar el mDNS reflector. El descubrimiento de servicios no concede acceso a las aplicaciones; la compatibilidad HA no garantiza sesiones de aplicación sin interrupciones. Esta afirmación sobre mDNS se aplica a SFOS 23, no a SFOS 22.

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 Appliance, por ejemplo XGS 2100 con XGS 2100.
• Revisión de hardware: Pueden utilizarse revisiones de hardware distintas del mismo modelo XGS Appliance.
• Modelos XGS Appliance 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 XGS Appliance 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. Algunos ejemplos de plataformas virtuales son Microsoft Hyper-V, VMware y Nutanix Prism; los appliances de software se ejecutan en hardware propio. La mención de una plataforma no sustituye la comprobación de los siguientes requisitos HA.

• Plataforma: Mismo tipo de appliance y plataforma SFOS.
• Hypervisor: Mismo tipo de hypervisor.
• Recursos: Recursos de hardware asignados idénticos, incluido el mismo número de núcleos de CPU, así como 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 SFOS 22 o Use interface MAC address en SFOS 23; en appliances virtuales ambas usan la MAC asignada por el hypervisor, por lo que estos cambios de plataforma no serán necesarios. La opción de SFOS 23 también usa la MAC de interfaz en appliances hardware en lugar de la MAC virtual del clúster. Activarla o desactivarla actualiza la configuración de interfaces y 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.

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 el Auxiliary pasivo.

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. El 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 el 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 Fusion (antes 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 el Primary.
• Sophos Central Management: Sincronizar las licencias y registrar los dispositivos no significa automáticamente que los firewalls puedan administrarse mediante Sophos Fusion Firewall Management. Se requiere una suscripción adicional adecuada.
• RMA y soporte: Advance Hardware Replacement requiere Enhanced Plus Support en el 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 Fusion

Un par HA puede conectarse a switches de la capa de acceso, incluidos Sophos Switches. Sophos Fusion, permite administrar de forma centralizada los firewalls y los Sophos Switches. Esto no sustituye un diseño de switches redundante: un switch compartido puede seguir afectando a ambos nodos. La descripción general anterior de SFOS 23 todavía utiliza el nombre Sophos Fusion; esto no implica una arquitectura HA diferente.

Un par HA ya creado se administra en Sophos Fusion 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 Fusion se unen en un par HA, Sophos recomienda dar de baja del registro a 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 el Primary actual, ir a System > Sophos Central y seleccionar Register both HA devices. Después, activar Central Management y, en Sophos Fusion bajo My Products > Firewall Management > Firewalls, abrir Approval Pending para el Primary y confirmar accept-services. Tras unos minutos, el par debería aparecer una sola vez con el icono HA; los cambios desde Sophos Fusion 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 dar de baja del registro a 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 – solo Active-Passive: Si las suscripciones de Active-Passive se asignaron por error al Auxiliary en lugar de al Initial Primary que posee las licencias, la sincronización no es suficiente. Antes de cualquier cambio, documentar el número de serie de origen del Auxiliary que recibió las licencias por error y el número de serie de destino previsto del Initial Primary, por separado de los roles HA actuales, y cotejarlos en SFOS y Sophos Fusion. Este procedimiento abreviado de corrección solo se aplica si el Primary actual y el Initial Primary son el mismo dispositivo físico. Si son distintos o la asignación no está clara, detenerse antes de desactivar HA o transferir las licencias y aclarar el procedimiento aplicable mediante las instrucciones de Sophos o con Sophos Support; no improvisar un cambio de rol de vuelta. Solo cuando la asignación sea inequívoca, desactivar HA de forma planificada en el Primary actual, transferir las suscripciones en Sophos Fusion desde el número de serie de origen documentado al número de serie de destino documentado del Initial Primary y volver a configurar el clúster Active-Passive. Las transferencias de licencias también son relevantes para RMA o cambios de modelo, pero requieren el procedimiento aplicable al caso concreto. Como los modelos HA deben ser idénticos, al cambiar de modelo deben sustituirse ambos dispositivos. En Active-Active, el Auxiliary también debe poseer sus propias licencias. Esto no es un error y no se corrige con esta transferencia. No reutilizar este procedimiento Active-Passive para RMA Active-Active sin instrucciones aplicables de Sophos.

Las licencias Active-Active caducadas o no sincronizadas pueden detener el balanceo de carga y desactivar HA. Para hardware y Virtual/Software, Sophos describe de forma contradictoria el inicio de la detención: el resumen lo sitúa al final de tres días, mientras los detalles lo sitúan dentro de los tres primeros días y la desactivación HA después. El inicio exacto sigue sin resolverse; no existe un periodo de gracia garantizado de tres días. Corregir los problemas de licencias cuanto antes y, si es necesario, acordar con Sophos Support un plan operativo seguro para el build instalado. Durante la configuración inicial, Active-Active no se activa si las licencias no coinciden.

En Active-Passive, sincronizar las licencias del Primary. El Initial Primary que posee las licencias debe sincronizarlas 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.

En Active-Active, tanto en hardware como en Virtual/Software, sincronizar individualmente las licencias de ambos dispositivos con Sophos Fusion y comprobar el éxito en el Primary y el Auxiliary. Los tipos de licencia coincidentes y la posesión de licencias no sustituyen este paso. En hardware, Base Firewall y Enhanced Support permanecen activos durante los problemas de licencias descritos; en Virtual/Software, una licencia Base Firewall desactivada desactiva HA y deja inactivas las demás licencias. No utilizar la indicación no resuelta de tres días como intervalo de sincronización.

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 correctamente por última vez; en Active-Active, registrar el estado y la hora de ambos nodos por separado
• 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 el Auxiliary Firewall.
• Direcciones de interfaces: Active-Active requiere direcciones IP estáticas en todas las interfaces. Active-Passive permite DHCP, DHCP Prefix Delegation o PPPoE. La conexión PPPoE no dispone de failover de sesión; esta limitación no establece una excepción general para las interfaces DHCP. Para las sesiones reenviadas, aplicar los límites por protocolo y servicio indicados arriba.

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. La limitación documentada de PPPoE no demuestra una exclusión general del failover de sesión en interfaces DHCP: la asignación de direcciones y el tráfico del protocolo DHCP son distintos de la conservación de sesiones TCP reenviadas. Aplicar los límites por protocolo y servicio indicados arriba, sin presumir una garantía general de conservación de sesiones en interfaces DHCP.

Las interfaces breakout se configuran en el Primary. Si se crea una nueva configuración breakout, reiniciar primero el Primary para aplicar el cambio y después el Auxiliary. Si el Primary ya tiene la configuración breakout correspondiente, reiniciar únicamente el Auxiliary después de la sincronización. Si el Primary no tiene una configuración breakout correspondiente, la sincronización elimina cualquier configuración breakout que exista solo en el Auxiliary. Los distintos casos se explican en Configurar interfaces breakout.

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 acceso administrativo al Auxiliary Firewall. QuickHA selecciona automáticamente la interfaz de la sesión WebAdmin actual; para acceder al Auxiliary, el endpoint de administración debe estar en la misma subred que su puerto de administración. Contradicción en las instrucciones oficiales: la documentación de modos y roles HA excluye de la sincronización el Dedicated HA link y los puertos de administración, y los requisitos de interfaces HA exigen para ambos puertos de administración direcciones IP estáticas diferentes en la misma subred. Sin embargo, la guía inicial del puerto de administración prohíbe usar IP diferentes en PortMGMT en HA porque afirma que la configuración se sincroniza. Una IP compartida de PortMGMT más una IP adicional para el peer no constituye una reconciliación documentada de estas instrucciones. Antes de configurar HA o cambiar direcciones de administración, documentar los roles Primary/Auxiliary actuales —o los previstos si los dispositivos aún son independientes—, el build exacto de SFOS instalado, la interfaz de administración seleccionada y las IP actuales de ambos nodos. Asegurar una copia de seguridad y una vía administrativa independiente mediante consola o acceso local. Verificar el comportamiento aplicable al build instalado mediante las instrucciones correspondientes o consultar a Sophos Support. Si la contradicción no queda resuelta para ese caso, detenerse antes de seleccionar Initiate HA o modificar las direcciones de administración.

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. El Primary es accesible desde cualquier zona donde HTTPS esté permitido bajo Administration > Device access. Para acceder a WebAdmin en el 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 del 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.

En SFOS 23, un Dedicated HA link con LAG o VLAN sobre LAG requiere Keepalive request interval × Keepalive attempts ≥ 2500 ms. El valor predeterminado de configuración de SFOS 23, 100 ms × 3 = 300 ms, no cumple este requisito de LAG y no debe aplicarse aquí sin cambios. Un ejemplo permitido es 250 ms × 10 intentos = 2500 ms, no un valor predeterminado universal. QuickHA crea un HA redundant link como LAG al seleccionar más de una interfaz física no vinculada, por lo que este requisito también se aplica a esa topología; verificar la configuración real del enlace. No suponer que QuickHA negocia automáticamente valores adecuados; verificar los valores configurados antes de confiar en el clúster.

Puertos de alta velocidad: Para los puertos de 25, 50 y 100 GbE de XGS 7500/8500 Series, seleccionar en ambos lados el mismo Link mode con velocidad y dúplex coincidentes en Network > Interfaces > Advanced settings y guardar con Save. A continuación, volver a abrir la interfaz para editarla, utilizar Show recommended settings > Load recommended configuration para la negociación y Forward Error Correction (FEC), y guardar de nuevo con Save. Si las recomendaciones siguen vacías después de guardar por primera vez y volver a abrir la interfaz, desactivar Auto-negotiation para Media Type y FEC, y guardar el cambio. En los demás puertos, utilizar Automatic o valores idénticos de velocidad y dúplex, y mantener MTU y MSS en sus valores predeterminados. Si QuickHA selecciona una interfaz no vinculada, SFOS restablece sus Advanced settings; comprobar de nuevo estos valores 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 la 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 y sus roles Primary/Auxiliary actuales —o los previstos si aún son independientes—.
• 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:

• Direccionamiento de administración verificado para el build instalado: Resolver antes la contradicción oficial descrita en Requisitos de red. Documentar roles Primary/Auxiliary actuales —o los previstos si los dispositivos aún son independientes—, build exacto de SFOS, interfaz de administración seleccionada e IP actuales de ambos nodos; asegurar una copia de seguridad y una vía independiente de consola o administración local. Verificar las instrucciones aplicables o consultar a Sophos Support. Si sigue sin resolverse, no seleccionar Initiate HA ni cambiar direcciones de administración.
• 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. Por ello, antes de sustituir un dispositivo en un par HA que todavía funciona, debe desactivarse HA y después configurarse de nuevo con el dispositivo de sustitución. Los apartados correspondientes más abajo explican el estado inicial específico después de una RMA y las descripciones divergentes del reimage.

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.

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.

Nombres de nodo en QuickHA: En SFOS 22, asignar un nombre es opcional. En SFOS 23, las instrucciones detalladas piden un nombre de nodo, mientras que las instrucciones de ejemplo siguen indicándolo como opcional. Por ello, la siguiente lista de comprobación asigna nombres distintos y fácilmente reconocibles a ambos dispositivos. Es una guía conservadora, no una prueba de que la GUI rechace un campo de nombre vacío.

Configurar HA

Active-Passive con QuickHA

1. Preparar el 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 un nombre de nodo único, 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 el 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 el 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 un nombre de nodo distinto del del Primary, por ejemplo FW02.
6. Introducir la misma passphrase HA.
7. Seleccionar el mismo puerto de enlace HA que en el Primary.
8. Seleccionar Initiate HA.

Una vez creado el clúster, el Primary Firewall sincroniza la configuración con el Auxiliary Firewall. Se sobrescriben muchos ajustes locales del 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 Fusion, si se utiliza

4. Definir Monitored Ports

Monitored Ports determinan si el fallo de una interfaz activa un failover. El campo de selección se llama Select ports to be monitored en SFOS 22 y Monitored interfaces en las instrucciones detalladas de SFOS 23. 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. Los Monitored Ports requieren direcciones IP estáticas en ambos modos HA.

SFOS 23 permite un máximo de 24 Monitored ports. Mantener la selección separada del Dedicated HA link e incluir solo enlaces productivos realmente necesarios.

HA también funciona sin seleccionar Monitored Ports. En ese caso, el fallo de un puerto productivo por sí solo no activa un failover; los fallos de heartbeat, del dispositivo o de alimentación pueden seguir activando un cambio de rol. Cada puerto seleccionado debe estar conectado en ambos nodos. La supervisión del estado de los puertos no detecta todos los fallos de un proveedor situado aguas arriba.

Los ajustes HA avanzados, como las interfaces supervisadas, la administración del peer, el Primary preferido y los valores keepalive, se modifican en el Primary actual después de establecer QuickHA. Antes, comprobar la copia de seguridad, la ventana de mantenimiento y la disponibilidad de un acceso administrativo seguro; para cambios de administración del peer o de sus direcciones, cumplir además la comprobación previa de Requisitos de red y detenerse si la contradicción sigue sin resolverse. El cambio de MAC descrito anteriormente provoca tiempo de inactividad. Si el enlace HA está basado en LAG, respetar el requisito de keepalive y no modificar los valores en estado Standalone o Faulty. Después de realizar la selección deseada, volver al principio de la página y seleccionar Initiate HA. Así, el Primary sincroniza los cambios con el Auxiliary. A continuación, comprobar en ambos nodos los roles HA, el estado, la sincronización y los valores modificados; si hay discrepancias, comparar primero el enlace HA y los logs de ambos dispositivos. Este paso final también se aplica a la variante Active-Active que se describe a continuación y debe distinguirse de la incorporación inicial de ambos dispositivos.

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 han sincronizado correctamente las licencias de ambos nodos individualmente y registrado el estado y la hora por separado?
• ¿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 el Auxiliary y después el Primary. Así se evita que expire la detección del peer en el Primary mientras todavía se prepara el segundo nodo.

1. Configurar el 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 del Auxiliary.

2. Configurar el 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 del Auxiliary. El campo se llama Dedicated peer HA link IPv4 address en SFOS 22 y Peer IPv4 address of dedicated HA link en las instrucciones detalladas de SFOS 23. Ambas direcciones del enlace HA deben estar en la misma subred. Esta no es la IP de administración del peer indicada en Peer administration settings.
5. Seleccionar los Monitored ports críticos; SFOS 23 permite como máximo 24.
6. En Peer administration settings, indicar la interfaz de administración y la dirección IP de FW02 solo después de resolver la comprobación previa de Requisitos de red para el build instalado. Si la contradicción sobre el direccionamiento sigue sin resolverse, detenerse sin cambiar la dirección ni seleccionar Initiate HA.
7. Si es necesario, seleccionar Use host or hypervisor-assigned MAC address para appliances virtuales en SFOS 22 o Use interface MAC address en SFOS 23. La opción de SFOS 23 usa la MAC del hypervisor en appliances virtuales y la MAC de interfaz en hardware, en lugar de la MAC virtual del clúster. Activarla o desactivarla 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. SFOS 22 permite intervalos de 250–500 ms y 16–24 intentos; los valores predeterminados de 250 ms y 16 intentos producen un timeout de 4 segundos. SFOS 23 permite 100–500 ms y 3–24 intentos; los valores predeterminados de 100 ms y 3 intentos producen 300 ms de timeout. En enlaces Dedicated HA de SFOS 23 con LAG o VLAN sobre LAG, el producto debe ser al menos 2500 ms: 250 ms × 10 intentos es un ejemplo permitido, no el valor predeterminado general. Comprobarlo también en los LAGs redundantes creados por QuickHA. Estos valores no pueden modificarse cuando los dispositivos tienen estado Standalone o Faulty. Después del timeout, el nuevo Primary realiza comprobaciones internas antes de empezar a procesar tráfico. Ninguno de estos timeouts garantiza un tiempo de recuperación del tráfico.

Discrepancia en la documentación de la API de SFOS 22: La descripción de Keepalive attempts indica 8–16 intentos, mientras que la restricción detallada del parámetro y el ejemplo XML indican 16–24. Para el build instalado, confirmar el rango admitido antes de escribir; 8–16 no es un segundo rango confirmado. Antes de realizar cambios, documentar el build de SFOS instalado y los valores keepalive actuales de ambos nodos. Si los límites aplicables siguen sin estar claros, aclararlos con Sophos Support antes de realizar un cambio; los requisitos de LAG deben seguir respetándose.

Comprobación previa de la API para SFOS 22 y 23: Las tablas de parámetros documentan ClusterId como un entero opcional de 0–63 con valor predeterminado 0 y NodeName como una cadena obligatoria de 1–30 caracteres. Incluso con el valor predeterminado documentado, cada clúster de la misma red Layer 2 debe utilizar una Cluster ID propia para evitar conflictos de MAC virtuales. Estos metadatos de la API no modifican las indicaciones anteriores sobre la asignación opcional u obligatoria de nombres en la GUI ni demuestran que la GUI aplique dicha validación. La tabla utiliza ClusterId y el ejemplo XML, ClusterID; esto no demuestra una correspondencia probada entre las etiquetas ni que exista un payload funcional para la API.

En los ajustes HA avanzados de SFOS 23, Monitor hardware components es opcional y añade un desencadenante de failover cuando se detecta un problema en un dispositivo de almacenamiento, además de la detección de fallos de heartbeat e interfaces monitorizadas. No suponer que esté activado por defecto ni que detecte todos los fallos de hardware.

Nota sobre la API de SFOS 23: La tabla de parámetros de la API incluye HardwareMonitor como parámetro escalar opcional (SCALAR, Mandatory: No), con los valores Enable y Disable y el valor predeterminado documentado para la API Enable. Este dato de la documentación no demuestra el ajuste real de la GUI ni el estado del dispositivo en ejecución. Comprobar el ajuste en el dispositivo instalado; el alcance limitado a dispositivos de almacenamiento descrito arriba no cambia.

El ejemplo XML de la API de SFOS 23 sigue incluyendo Number(250-500) y Number(16-24). Estos marcadores no coinciden con los rangos de la tabla, 100–500 ms y 3–24 intentos, y no deben copiarse como límites completos. Esto no demuestra que el producto rechace los valores inferiores ni un comportamiento probado de la API.

Conectar un nuevo Auxiliary virtual como HA spare

Para un nuevo Auxiliary virtual en Active-Passive, el Setup Assistant puede usar Connect as HA spare. Este procedimiento es una alternativa a la configuración descrita anteriormente con dos dispositivos ya existentes, en la que se prepara primero el Auxiliary: la nueva VM spare no se configura previamente como Auxiliary. Antes de seleccionar Initiate HA, complete la comprobación previa sobre el direccionamiento de administración descrita en Requisitos de red; la configuración automática del puerto de administración no resuelve la contradicción documental. Si sigue sin resolverse para el build instalado, deténgase antes de seleccionar Initiate HA o cambiar las direcciones de administración. Active-Active o dos firewalls Virtual/Software ya existentes siguen requiriendo QuickHA o Interactive mode en ambos dispositivos.

1. En el Primary existente, permita SSH para DMZ bajo Administration > Device access y seleccione Primary (active-passive) e Interactive mode en System services > High availability. En SFOS 23, introduzca una Cluster ID y un nombre de nodo antes de seleccionar Initiate HA; las instrucciones de SFOS 22 describen la introducción de la Cluster ID y el cambio del nombre de nodo como opcionales. Si hay varios clústeres HA en la misma red Layer 2, utilice una Cluster ID distinta para cada clúster a fin de evitar conflictos de direcciones MAC virtuales. Documente de forma segura el Dedicated HA Link, su propia IP y máscara de subred, la IP prevista del peer, Peer Administration y la passphrase HA utilizada en el Primary. Después, seleccione Initiate HA; en SFOS 23, vuelva al principio de la página para hacerlo. En este punto, antes de que se una la nueva VM, las instrucciones de Sophos para la spare documentan el mensaje HA could not be enabled y, temporalmente, el estado Standalone. Por sí solos, estos dos indicadores en esta fase de configuración aún no demuestran el fallo de un clúster ya terminado.
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 del Primary existente, la misma passphrase HA utilizada previamente en el Primary y documentada de forma segura, y la misma interfaz Dedicated HA Link. Para la nueva spare, utilice una dirección IP propia, libre y distinta de la del Primary, en la subred del Dedicated HA Link del Primary existente y con una máscara de subred idéntica; debe coincidir con la IP del peer preparada allí. No presuponga una passphrase de un Auxiliary supuestamente ya configurado.
4. Seleccione Apply, Continue y Finish. SFOS crea el 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 del Auxiliary y vuelva a iniciar sesión. Compruebe después en el 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 el 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 el propio 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 el propio 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 Fusion, 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 Fusion 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.

El 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.

En Active-Active, la IP de origen ofrece una primera pista sobre el nodo donde deberían aparecer los logs: para el tráfico TCP apto, las direcciones pares corresponden al Primary y las impares al Auxiliary. Esto no se aplica de forma general a los tipos de tráfico excluidos anteriormente ni sustituye la comparación de ambos dispositivos, especialmente después de un cambio de rol.

Para los eventos HA, abrir Log viewer > System por separado en cada nodo. Mediante Add filter, seleccionar el filtro y el valor adecuados para el periodo afectado y aplicarlos con el botón Add filter. Para un análisis detallado, abrir Diagnostics > Tools > Troubleshooting logs > Select files en ambos dispositivos y seleccionar csc.log, correspondiente al servicio central que administra los demás servicios. Seleccionar además los archivos HA descritos más abajo en Logs y ubicaciones de diagnóstico importantes y guardar cada paquete por separado con Download. Para reconstruir la secuencia de funcionamiento del clúster, comparar los registros de ambos nodos y comprobar si hay lagunas temporales o logs rotados.

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 el 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 el Primary o el Auxiliary solo para resolver un problema de sincronización confirmado. El 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 del Auxiliary con Switch to passive device en el Primary actual o Switch to active device en el Auxiliary actual. El 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

Las preguntas frecuentes de Sophos sobre HA para SFOS 22 y 23 establecen como requisito general desactivar HA antes de un reimage, antes de sustituir un nodo del par HA y antes de transferir licencias entre los nodos. La passphrase de un solo uso para el túnel SSH se elimina después de establecerlo; por ello, para un dispositivo nuevo debe desactivarse HA y configurarse de nuevo. Este requisito no sustituye la planificación específica de cada caso: los detalles de reimage que siguen contienen una discrepancia documental, y los procedimientos RMA presuponen que ya hay un nodo sano en estado Standalone HA. Planificar previamente la copia de seguridad, el acceso administrativo asegurado, la ventana de mantenimiento y la reconstrucción; para la corrección de licencias Active-Passive, cumplir además la condición sobre números de serie y roles descrita anteriormente.

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

Acceso desde Fusion a partir de SFOS 22 MR1: Los Sophos Known Issues, NC-186855, describen una excepción al comportamiento general anterior: si se desactiva HA en la interfaz del firewall abierta mediante FRP-SSO desde Sophos Fusion/Central, el Auxiliary puede permanecer en estado Standalone con HA activado, mientras que HA ya está desactivado en el Primary. Esto entraña riesgo de split brain. Después de la acción, comprobar por separado el estado de HA en ambos dispositivos. Si los estados son incoherentes, detener la reconstrucción prevista y coordinar la recuperación con Sophos Support antes de volver a operar los dispositivos como pareja. Un diálogo satisfactorio en el Primary no basta como comprobación. A 24 de octubre de 2026, la entrada no indica ninguna versión corregida.

Actualizaciones de firmware y copias de seguridad

Actualizaciones de firmware en entornos HA

Las actualizaciones de firmware se inician en el 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 el Primary Firewall.
2. Se actualiza el Auxiliary Firewall.
3. El Auxiliary Firewall se reinicia y asume temporalmente el servicio.
4. Se actualiza el Primary anterior.
5. El 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 sufrir una breve interrupción o necesitar volver a conectarse.

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 el Primary y se sincronizan automáticamente con el 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:

Active-Active y Bridge-VLAN: Cada nodo escribe sus propios logs. En SFOS 22 Active-Active, solo el Primary procesa el tráfico recibido en interfaces VLAN configuradas en Bridge Interfaces. Las descripciones de configuración e interfaces de SFOS 23 omiten esta restricción, pero la omisión no confirma un reparto de carga. Hasta que Sophos Support confirme el comportamiento para el build de SFOS 23 y la topología utilizados, planificar este tráfico de forma conservadora solo en el Primary y no depender de su distribución para dimensionar la capacidad.

Acceso a la cuarentena: Cada nodo almacena su propia cuarentena y envía su propio Quarantine Digest. Los administradores liberan un email en el nodo que lo procesó. Los usuarios liberan los emails en cuarentena a través del User Portal. El User Portal solo muestra emails en cuarentena del Primary actual.

Precaución con una copia sin HA: Las descripciones de Sophos para SFOS 22 y 23 se contradicen sobre el estado del Auxiliary tras esta restauración: el texto indica que conserva la configuración anterior, mientras que el resumen indica un restablecimiento de fábrica, salvo el Peer Admin Port y el Dedicated HA Link. Por tanto, ni la conservación completa ni el restablecimiento de fábrica quedan demostrados como comportamiento confirmado. No confiar en que se conserve la configuración del Auxiliary. Antes, guardar las configuraciones externamente, documentar las IP de administración y las credenciales, y prever tiempo de inactividad y la reconstrucción de HA. Antes de depender del estado incierto del Auxiliary, aclarar el procedimiento para el build de SFOS instalado con Sophos Support.

Si el Primary estaba registrado 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, solo se aplica a Active-Passive. Antes, ejecutar system diagnostics show version-info en Device Console de ambos nodos, documentar el firmware incluido el build y el Initial Primary, y guardar externamente una copia de seguridad actual.

Ámbito de aplicación de los siguientes procedimientos: Al principio, FW1 es tanto el Primary actual como el Initial Primary titular de la licencia; FW2 es el Auxiliary actual. Estos nombres identifican los mismos dispositivos físicos durante todo el procedimiento, incluso después de un cambio de rol. El objetivo es volver a tener FW1 como Primary y FW2 como Auxiliary. Si el Primary actual y el Initial Primary son dispositivos diferentes, no improvisar siguiendo estos procedimientos: primero identificar los roles y el titular de la licencia mediante las instrucciones de Sophos correspondientes o con Sophos Support.

Aclarar la discrepancia documental antes del reimage: Las preguntas frecuentes sobre HA para SFOS 22 y 23 exigen, de forma general, desactivar HA antes del reimage. Sin embargo, las instrucciones detalladas de Active-Passive describen, tanto para el reimage del Primary como para el de ambos nodos, un cambio de rol mediante Switch to passive device seguido de una reinstalación, sin mencionar un paso separado de Disable HA. El cambio de rol no equivale a desactivar HA; la omisión no demuestra que exista una excepción segura de aplicación general. Por ello, las secuencias detalladas que siguen se conservan como procedimientos documentados, pero contradictorios en este punto. Antes de ejecutarlos, definir un plan firme para los roles, el Initial Primary, el build instalado, la copia de seguridad, el tiempo de inactividad y la vía de reversión, y aclarar el orden adecuado con Sophos Support si se necesita seguir esta secuencia detallada divergente. Si el orden no está claro, detenerse antes del cambio de rol o de la reinstalación; no añadir por iniciativa propia un paso de desactivación a la secuencia.

Si FW1 está registrado para Central Management, darlo de baja de ese registro antes de cada uno de los tres procedimientos. Después, comprobar en el mismo tenant de Sophos Central/Fusion, en My Products > Firewall Management > Firewalls, que la entrada de FW1 ya no existe. Solo entonces continuar con la copia de seguridad, la desactivación de HA o el cambio de rol. Esta comprobación se aplica al registro en Firewall Management, no solo a Synchronized Security.

Reinstalar solo el Auxiliary FW2

1. Después de dar de baja el registro y realizar la comprobación descritos anteriormente, guardar externamente la copia de seguridad de FW1 y desactivar HA en FW1, nunca en FW2.
2. En Advanced Shell de FW1, comprobar con service -S | grep msync que msync muestra el estado UNTOUCHED o STOPPED. De lo contrario, no continuar.
3. Reinstalar FW2 con exactamente la misma versión de firmware, incluido el build, que FW1. Iniciar sesión localmente y configurar únicamente WAN para Internet, sin interfaces LAN ni DMZ. Después, registrar FW2 mediante claiming si aún no se ha hecho.
4. Reconstruir HA con FW1 como Primary y FW2 como Auxiliary.

Reinstalar solo el Primary FW1

1. Después de dar de baja el registro y realizar la comprobación, guardar externamente la copia de seguridad de FW1 y utilizar Switch to passive device para que FW2 asuma el servicio. Las identidades de los dispositivos no cambian.
2. Reinstalar FW1 con exactamente la misma versión de firmware, incluido el build, que FW2. Iniciar sesión localmente, configurar solo WAN para Internet, sin interfaces LAN ni DMZ, y registrar FW1 mediante claiming si aún no se ha hecho.
3. Para la restauración, desconectar todos los cables de FW1 excepto el del PC de administración, restaurar la copia de seguridad, volver a conectar los cables y devolver el tráfico de FW2 a FW1.
4. Después, restablecer FW2 a los valores de fábrica. Iniciar sesión localmente, configurar únicamente WAN para Internet, sin interfaces LAN ni DMZ, y registrar el dispositivo mediante claiming si aún no se ha hecho.
5. Reconstruir HA con FW1 como Primary y FW2 como Auxiliary.

Reinstalar y actualizar ambos nodos

1. Dar de baja el registro, realizar la comprobación, guardar la copia de seguridad y cambiar los roles como en el reimage del Primary. Sin embargo, instalar en FW1 la versión de destino, incluido el build de destino. Después, iniciar sesión localmente, configurar solo WAN para Internet, sin interfaces LAN ni DMZ, y registrar el dispositivo mediante claiming si aún no se ha hecho.
2. Para la restauración, desconectar todos los cables de FW1 excepto el del PC de administración, restaurar allí la copia de seguridad, volver a conectar los cables y devolver el tráfico de FW2 a FW1.
3. A diferencia del reimage exclusivo del Primary, ahora no basta con restablecer FW2 a los valores de fábrica: también debe reinstalarse con exactamente la misma versión de destino, incluido el build, que FW1. Iniciar sesión localmente, configurar únicamente WAN para Internet, sin interfaces LAN ni DMZ, y registrar el dispositivo mediante claiming si aún no se ha hecho.
4. Reconstruir el clúster Active-Passive con FW1 como Primary y FW2 como Auxiliary. La interrupción planificada también incluye este segundo paso de reinstalación e incorporación.

Si el clúster utiliza Sophos Fusion 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 el 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. Las dos variantes RMA detalladas presuponen que el nodo sano restante ya funciona como Standalone HA: el Primary sano en la RMA del Auxiliary y el Auxiliary sano en la RMA del Primary. Solo para este estado inicial, las fuentes describen el claiming y la transferencia de licencia del dispositivo de sustitución antes de la posterior desactivación de HA o del restablecimiento del nodo sano, respectivamente. No aplicar este orden a la sustitución en un par HA que todavía funciona; en ese caso rige el requisito general de desactivación previa de las preguntas frecuentes. Si el estado inicial no coincide o no está claro, detenerse antes de la sustitución o de la transferencia de licencia y planificar el procedimiento 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 el Primary sano.
2. Preparar primero el acceso local al dispositivo de sustitución. En el ejemplo de puertos documentado, conectar un PC de administración capaz de obtener una dirección por DHCP al puerto 1 y abrir https://172.16.16.16:4444; conectar WAN al puerto 2 y configurarla para Internet en el Setup Assistant. Si la distribución de puertos es diferente, utilizar los puertos de administración y WAN correspondientes al modelo del dispositivo. No configurar ninguna otra interfaz. Solo después, registrar el dispositivo de sustitución mediante claiming en Sophos Fusion y transferir la licencia del dispositivo Auxiliary defectuoso.
3. Cambiar los cables del dispositivo defectuoso al de sustitución.
4. En el Primary sano, 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 el Primary sano como Primary y el dispositivo de sustitución como Auxiliary.

Sustituir el Primary después de RMA

1. Descargar una copia de seguridad actual del Auxiliary sano y dar de baja el dispositivo del registro de Sophos Fusion. Antes de continuar, comprobar en el mismo tenant de Sophos Central/Fusion, en My Products > Firewall Management > Firewalls, que la entrada de este Auxiliary sano ya no existe.
2. Instalar en el dispositivo de sustitución el mismo build de firmware e iniciar sesión localmente. En el ejemplo de puertos documentado, conectar un PC de administración capaz de obtener una dirección por DHCP al puerto 1 y abrir https://172.16.16.16:4444; configurar WAN en el puerto 2 para Internet mediante el Setup Assistant. Si la distribución de puertos es diferente, utilizar los puertos de administración y WAN correspondientes al modelo del dispositivo. No configurar ninguna otra interfaz. Solo después, registrar el dispositivo mediante claiming en Sophos Fusion y transferir la licencia del Primary defectuoso.
3. Restaurar la copia de seguridad en el dispositivo de sustitución.
4. Cambiar los cables del Auxiliary sano al dispositivo de sustitución. Desde ese momento, el dispositivo de sustitución procesa el tráfico como firewall independiente.
5. Restablecer el Auxiliary anterior a los valores de fábrica y preparar de nuevo el acceso local: en el ejemplo de puertos documentado, conectar un PC de administración capaz de obtener una dirección por DHCP al puerto 1 y abrir https://172.16.16.16:4444; después, configurar WAN en el puerto 2 para Internet mediante el Setup Assistant. Si la distribución de puertos es diferente, utilizar los puertos de administración y WAN correspondientes al modelo del dispositivo. No configurar ninguna otra interfaz. Solo después, volver a registrar el dispositivo mediante claiming en Sophos Fusion 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: Diagnostics > Tools > Troubleshooting logs > Select files 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 al 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 Appliance idénticos y compatibles.

• HA could not be enabled: Sophos solo documenta este mensaje inmediatamente después de Initiate HA en el Primary, antes de que se una la spare, para la configuración con una nueva HA spare virtual descrita anteriormente; también se describe allí el estado temporal Standalone. Esto no justifica ignorar el mensaje en general. Si persiste después de completar el asistente de la spare y la fase de espera y actualización, o si aparece en otra configuración, es posible que el Dedicated HA link no esté conectado o que el peer no sea accesible. Asegurarse de que las interfaces dedicadas del enlace HA de ambos dispositivos estén conectadas directamente mediante un cable Ethernet o a través del switch previsto. Comprobar en ambos nodos, bajo Network > Interfaces, que la interfaz seleccionada para el enlace HA muestre Connected. En el Primary, utilizar la herramienta ping de Diagnostics > Tools para comprobar la IP del enlace HA dedicado del Auxiliary, no su dirección Peer Admin. Las respuestas demuestran la conectividad básica, pero no que la sincronización HA haya finalizado. Si no hay respuestas, comprobar y corregir primero el cable, la ruta por switches, el estado del enlace y la IP y subred del enlace HA; después, repetir el ping y volver a comprobar los roles y la sincronización.

• 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 del 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: Buscar este mensaje exacto en /log/syslog.log en el Primary. Sophos lo atribuye a puertos de administración que no están en la misma subred; comparar las direcciones de los puertos de administración de ambos dispositivos. Comprobar además, como requisito independiente, que las direcciones del enlace HA estén en la misma subred, sin considerarlas una causa demostrada de este mensaje. Antes de corregir el direccionamiento de administración, cumplir la comprobación previa descrita anteriormente para aclarar la contradicción entre las fuentes: documentar los roles, el build de SFOS instalado, la interfaz de administración y las IP actuales, asegurar una copia de seguridad y un acceso administrativo independiente mediante consola o acceso local, y verificar el comportamiento de direccionamiento aplicable o aclararlo con Sophos Support. Si el comportamiento sigue sin estar claro, detenerse antes de modificar las direcciones.

• 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 Fusion 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 falla después de una actualización: En los modelos 1U XGS 2100, XGS 2300, XGS 3100, XGS 3300, XGS 4300 y XGS 4500, HA puede no establecerse si se utiliza un Flexi Port como Dedicated HA link. Después de actualizar y reiniciar el primer dispositivo, su Interface speed deja de estar en Auto negotiation, mientras que el segundo sigue utilizando Auto negotiation.

  Antes de cambiar el ajuste: Documentar los roles HA y los ajustes de puerto de ambos dispositivos, asegurar una copia de seguridad y un acceso administrativo independiente, y utilizar una ventana de mantenimiento. Si hay split-brain, seguir primero el procedimiento de fallo del enlace HA que aparece a continuación: decidir qué nodo debe permanecer activo y desconectar el otro de la red de producción o apagarlo de forma controlada. No reiniciar ambos nodos sin coordinación.

  1. En ambos dispositivos, abrir Network > Interfaces.
  2. Seleccionar la interfaz Flexi Port afectada y abrir Advanced settings.
  3. Establecer Interface speed en Auto negotiation.

  Después, comprobar el estado del enlace, los roles HA, la sincronización y el tráfico de producción. Si el problema persiste, guardar los ajustes y los logs de ambos nodos y recurrir a Sophos Support. Restaurar los valores anteriores documentados solo mediante un cambio controlado y con acceso administrativo asegurado; esto puede volver a provocar el fallo del enlace HA. Como alternativa, planificar el uso de un puerto integrado como Dedicated HA link, no de un valor de velocidad fijo.

WebAdmin y VPN Portal inaccesibles por la sincronización de certificados

Las notas de versión de SFOS 22.0 MR3 Build 576 del 16 de octubre de 2026 incluyen la corrección de NC-186809: la sincronización de certificados podía fallar en la Auxiliary cuando determinados nombres de archivo de certificado comenzaban por dos caracteres de punto consecutivos (..), lo que impedía acceder a WebAdmin y VPN Portal. Distinguir este caso de problemas generales de routing o Device Access y guardar el build, el nodo afectado, la hora y los registros de sincronización disponibles. No renombrar ni eliminar certificados por sospecha. Si el caso coincide, recurrir al soporte y planificar un cambio de firmware compatible con el acceso de gestión asegurado; después, volver a comprobar ambos portales y la sincronización HA.

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 el estado de interfaces y enlaces:

show network interfaces

Se esperan estados UP para el Dedicated HA link y los Monitored Ports conectados.

En la misma salida de show network interfaces, localizar la interfaz física afectada por su nombre real y comprobar, además del estado del enlace, los contadores disponibles de paquetes descartados (Drops), errores y colisiones. No todos los builds muestran todos los contadores; la ausencia de datos no equivale a un valor cero. Guardar la salida con el nodo, la interfaz y el timestamp, y compararla con una observación posterior: los contadores que aumentan ayudan a acotar problemas de interfaz, cable o negociación, pero por sí solos no demuestran una causa concreta. Sustituir el cable o corregir la velocidad y el dúplex solo de forma controlada, con acceso administrativo asegurado y las precauciones HA y de split-brain descritas anteriormente; después, volver a comparar los contadores, el estado del enlace, los roles y la sincronización. Estos contadores de interfaz deben distinguirse de los paquetes descartados por reglas de firewall y de su Drop Capture.

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.

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 al 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