Setting Up Sophos Firewall High Availability (HA)

High Availability, or HA, connects two Sophos Firewalls into a cluster. In most environments, Active-Passive with QuickHA is the best choice: one firewall processes the traffic, while the second takes over during a failure or maintenance. Before starting, verify that both devices, firmware builds, licences, cabling and management access meet the HA prerequisites.

This article covers the process from choosing the HA mode through setup to failover testing, operation and RMA. HA replaces neither sound network design nor backups.

Choose the HA Mode and Architecture

Avanet operational recommendation: In most production environments, Active-Passive is the better HA option. One firewall processes all traffic, while the second remains ready and takes over during a failure or maintenance. The design is simpler, licensing costs less and behaviour during a failure is easier to understand. This is a design recommendation, not a Sophos requirement.

Active-Active is worthwhile only when its limitations are deliberately accepted. It is not conventional symmetric load balancing in which both firewalls have equal roles everywhere in the network. The Primary Firewall still receives the traffic and distributes specific connections to the Auxiliary Firewall. Not every service or type of traffic is distributed.

As a quick guide:

• Maximum stability and straightforward operation: Active-Passive.
• Use the second firewall without separate protection licences: Active-Passive.
• More throughput is required for specific TCP connections: Evaluate Active-Active.
• Many VPN, proxy, RED, NDR or special cases: Prefer Active-Passive.
• Small or medium-sized environment without a clear performance problem: Active-Passive.
• Clear performance requirement and appropriate licensing for both appliances: Use Active-Active after testing.

The two Sophos Techvids show the setup and role changes visually:

What High Availability Means

A Sophos Firewall HA cluster consists of two firewalls. The devices exchange heartbeats, device status, connection information and configuration data over a dedicated HA link. The configuration is synchronised from the Primary Firewall to the Auxiliary Firewall.

HA protects against common failures:

• Failure of the Primary Firewall
• Power or hardware failure
• Failure of a monitored interface
• Software or service problem that prevents a device from operating
• Planned firmware updates
• Planned role changes during maintenance

However, HA does not solve every problem:

• An incorrect firewall rule set remains incorrect in a cluster.
• A shared switch failure can affect both firewalls simultaneously.
• A defective VLAN design or incorrect routing concept is not corrected automatically.
• Logs and reports are not synchronised between the two firewalls.
• A backup remains mandatory.

Before planning HA, the fundamentals of zones, interfaces, VLANs, LAGs and bridges should be clear. See Planning and Configuring Sophos Firewall Zones and Interfaces.

Active-Passive or Active-Active

Active-Passive

With Active-Passive, one firewall processes all production traffic. The second firewall remains passive and takes over only when the active firewall fails or when failover is triggered manually or by maintenance.

Typical characteristics:

• The Primary Firewall processes the traffic.
• The Auxiliary Firewall remains on standby.
• Sessions are synchronised where the respective service supports it.
• For hardware appliances, only the licence-holding device requires the protection subscriptions.
• When the cluster virtual MAC is used, the Auxiliary Firewall takes over with the same virtual MAC address during failover.
• In this virtual-MAC case, network devices generally do not need to relearn their neighbours.

Active-Passive is usually the best choice for conventional business environments, branch offices, data centres and environments where stability matters more than a potential performance gain.

Active-Active

With Active-Active, both firewalls process traffic. The architecture nevertheless remains asymmetric: the Primary Firewall receives the traffic and decides whether to process a connection itself or forward it to the Auxiliary Firewall.

Sophos uses the source IP address for distribution: eligible TCP connections from even-numbered source IP addresses are processed by the Primary, while those from odd-numbered addresses go to the Auxiliary. Forwarded TCP traffic and translated TCP connections are distributed, including SNAT and virtual-host traffic, also over VLAN interfaces. After the Auxiliary processes a connection, it sends packets directly to the destination rather than back through the Primary. This even-odd method is fixed and cannot be changed. Layer 7 support varies: according to Sophos, the DPI Engine, transparent, direct and parent proxies, SMTP proxy traffic and HTTPS support load balancing. Scanned FTP and H.323 do not. Also excluded are non-TCP traffic such as UDP, ICMP, multicast and broadcast, SD-RED, and tunnelled TCP and non-TCP traffic, including VPN. External load balancers are not supported for HA.

Both nodes require appropriate licences and store logs locally for the traffic they process. Active-Active therefore makes sense only when there is a clear performance objective and the relevant traffic demonstrably benefits from distribution. For high availability alone, Active-Passive is usually the cleaner choice.

Roles, Status and Failover

Roles in the HA Cluster

• Primary: Device that maintains the central cluster configuration. The Primary receives the traffic in both HA modes.
• Auxiliary: Second device in the cluster. It synchronises its configuration from the Primary and takes over when required.
• Initial primary: Device that started as Primary during setup. In Active-Passive, it is generally also the licence-holding device. This ownership remains unchanged whether the node is currently Active or Passive.
• Preferred primary: Preferred device that should become Primary again after failover once it is stably available.

In Active-Passive mode, WebAdmin on the Auxiliary doesn’t show Live users, DHCP leases, or active IPsec connections. This is expected behaviour and isn’t evidence of failed synchronisation. The currently active Primary is authoritative for these runtime details.

Status Values During Operation

• Active: The device is processing traffic.
• Passive: The device is ready but does not process production traffic in Active-Passive.
• Standalone: The device cannot see its peer or HA is not fully active. Both devices can become Standalone when the HA link fails.
• Faulty: The device is not healthy enough to participate normally in the cluster.

Virtual MAC Address

When the HA cluster virtual MAC is used, SFOS assigns virtual MAC addresses to physical interfaces, except for the Dedicated HA Link and administration ports. The Dedicated HA Link uses its own physical MAC address. Only the Primary answers ARP requests for the cluster. During failover, the Auxiliary takes over the virtual MAC address of each production interface. This helps maintain reachability for switches, routers and clients because the IP-to-MAC mapping does not fundamentally change. The interface-MAC option described below is a different branch; do not assume the same virtual-MAC takeover behaviour for it.

The Cluster ID is important because it is used for the virtual MAC address. If several HA clusters operate in the same Layer 2 environment, each cluster must use a unique Cluster ID. Otherwise, MAC conflicts can occur.

What Is Synchronised

• Firewall rules, policies, objects, routing and CLI configuration are synchronised from Primary to Auxiliary.
• Active sessions are synchronised depending on the protocol and service. In Active-Active, both devices exchange the status and details of active sessions with their peer; configuration synchronisation, however, remains directed from Primary to Auxiliary.
• Secure Storage Master Key and WebAdmin credentials are synchronised.
• Dedicated HA link and administration ports are explicitly excluded from configuration synchronisation in the official HA modes and roles documentation.
• Logs and reports are not synchronised between the devices.

Failover Behaviour

In Active-Passive, the Auxiliary takes over all traffic if the Primary fails. In Active-Active, however, failure of either active device can trigger a takeover by the healthy peer. If the Auxiliary fails, the Primary processes all traffic alone; this does not necessarily involve a role change. When a peer becomes unavailable, the remaining device operates as Standalone. This status alone therefore does not prove that the HA link has failed on both sides; check the roles and reachability of both nodes before applying the split-brain runbook.

Several events can trigger failover:

• Heartbeats are no longer received over the HA link
• Failure of a monitored port
• Power failure
• Hardware failure
• Software or service problem
• Planned role change
• Firmware update

If one Node starts in Failsafe mode, first document its role and the peer’s state. Check Sophos Firewall in Failsafe mode describes the safe diagnostic procedure and explains why both Nodes must not be restarted without coordination or HA disabled based only on suspicion.

Heartbeats over the Dedicated HA Link are VRRP requests. SFOS 22 defaults to 250 ms and 16 missed heartbeats, giving a 4-second heartbeat timeout. SFOS 23 defaults to 100 ms and 3 attempts, giving a 300 ms heartbeat timeout; LAG-based HA links require different values as explained below. These timeouts are not guaranteed traffic-recovery times. For Monitored Ports, however, a single failed port is sufficient for the device to be considered unavailable and for failover to be triggered.

Conflicting heartbeat figures for SFOS 23: The general failover description still specifies 250 ms and 16 attempts, while the detailed SFOS 23 setup specifies 100 ms and 3 attempts. The SFOS 23 defaults stated here come from the detailed setup guide, not from measurements on a device. Before making a change under System services > High availability, document the actual configured values and HA link topology on both nodes. Neither the older figures nor the shorter setup default is a reason to change an existing cluster without checking it first; if the values are unclear or do not meet the LAG requirement, clarify the plan with Sophos Support.

After failover, WebAdmin on the former Auxiliary Firewall shows the Primary configuration. Different limits apply to active sessions:

When the Initial Primary returns, it remains the Auxiliary in the cluster unless Preferred primary is selected. If it is configured as the Preferred primary, SFOS first synchronises services and then switches back automatically. The device that had been operating alone restarts during this process. This failback must therefore be scheduled for a maintenance window. The role changes and restarts described here do not guarantee uninterrupted processing of existing connections.

Supported and Restricted Services

Sophos HA supports most firewall services, but their operating boundaries differ significantly:

If reporting or log retention is important, plan early whether to use an external syslog server or Sophos Central Firewall Reporting. See Enabling Central Firewall Reporting.

For configuration, security boundaries and tests, use Configure the mDNS reflector. Service discovery does not grant application access; HA support does not guarantee uninterrupted application sessions. This mDNS statement applies to SFOS 23, not SFOS 22.

Prerequisites and Network Design

Before implementation, check the HA prerequisites carefully against the environment. Small differences in models, firmware, interfaces, Cellular WAN or virtual platforms can have significant consequences later.

Hardware and Model Compatibility

• Appliance model: Both firewalls must be the same XGS Appliance model, for example XGS 2100 with XGS 2100.
• Hardware revision: Different hardware revisions are possible with the same XGS Appliance model.
• XGS Appliance Wi-Fi models: Not supported. Examples include XGS 126w and XGS 136w.
• Flexi Port Modules: If expansion modules are used, both devices must have the same number and model of Flexi Port module.
• Firmware: Both devices must run the same SFOS version, including Maintenance Release and build.
• Hardware plus virtual appliance: Cannot form an HA pair.

Important: Flexi Port modules aren’t hot-swappable. To add modules, shut down both firewalls in a controlled manner, install the same module model in both devices, and restart both devices. Then configure the new Flexi Ports only on the current Primary under Network > Interfaces. SFOS synchronizes this port configuration to the Auxiliary. Don’t modify only one node while the cluster is running.

SFOS 22 no longer supports XG or SG Series hardware. Before migrating to SFOS 22, these devices must be replaced with a supported XGS Appliance or an appropriate virtual platform.

Virtual and Software Appliances

Virtual and software appliances must also match closely. Examples of virtual platforms include Microsoft Hyper-V, VMware and Nutanix Prism; software appliances run on your own hardware. Listing a platform does not replace checking the following HA requirements.

• Platform: Same appliance type and SFOS platform.
• Hypervisor: Same hypervisor type.
• Resources: Identically allocated hardware resources, including the same number of CPU cores, and the same number of network interfaces.
• Firmware: Same SFOS version, including build.
• MAC addresses: In virtual environments, the option for hypervisor-assigned MAC addresses can avoid the need for promiscuous mode. Changing this option causes downtime.

If the cluster uses the virtual MAC address generated by SFOS, the virtualisation platform must accept MAC changes. In VMware ESXi, set MAC Address Changes and Forged Transmits to Accept on the vSwitch or port group; port groups must inherit the vSwitch values or be configured accordingly. In Hyper-V, enable Enable MAC address spoofing on all virtual network adapters of both firewalls except the adapter used for the Dedicated HA Link. Alternatively, select Use host or hypervisor-assigned MAC address in SFOS 22 or Use interface MAC address in SFOS 23; for virtual appliances, both use the hypervisor-assigned MAC, so these platform changes are then unnecessary. In SFOS 23, the latter option also uses the interface MAC on hardware appliances instead of the cluster virtual MAC. Turning the option on or off updates interface configuration and causes downtime.

Cloud Deployments

Cloud environments have additional platform requirements. Routing, virtual interfaces, IP addresses, security groups, UDRs and cloud-specific failover mechanisms must match the relevant cloud design. The normal appliance HA approach cannot be transferred to Azure, AWS or other cloud environments without review.

Before planning HA for a Sophos Firewall in the cloud, check the current Sophos documentation for the relevant platform and the cloud network architecture.

Gateway, Bridge and Discover/TAP

HA is available in gateway and bridge modes. Discover or TAP mode only supports Active-Passive. If at least one node operates in discover mode, an Active-Active cluster can’t be created. An active TAP interface also blocks Active-Passive setup. Disable the TAP interface on both firewalls through the CLI, establish HA, and then enable TAP individually on each node. TAP remains active on the passive Auxiliary.

Licensing and Registration

HA licensing differs by platform and HA mode. Three questions are decisive: Is the deployment hardware or Virtual/Software? Does it use Active-Passive or Active-Active? Which device is the Initial Primary and therefore holds the licence for the cluster? Compare these points with the licence status, serial numbers and target mode before implementation.

The key licensing points are:

• Base Firewall: HA requires a Base Firewall licence. Hardware appliances include it by default, but it ends when the device reaches end of life. The Base Firewall licence doesn’t expire on cloud, virtual and software appliances, but it must be present for HA.
• Active-Passive Hardware: Only the Initial Primary needs the production subscriptions. The Auxiliary Firewall receives a copy of the subscriptions and can process traffic after failover.
• Active-Active Hardware: Both firewalls require their own matching licences. Licence types must match, but expiry dates can differ.
• Active-Passive Virtual/Software: Only the Primary needs the required licences, including Base Firewall.
• Active-Active Virtual/Software: Both devices require their own Base Firewall licence and matching additional protection licences.
• Hardware registration: Both hardware devices must be claimed in Sophos Fusion (formerly Sophos Central) before HA setup and must be able to synchronise their licences.
• Virtual/Software Active-Passive registration: According to Sophos, only the Primary is claimed for Active-Passive Virtual/Software.
• Sophos Central Management: Licence synchronisation and claiming do not automatically mean that the firewalls can be managed through Sophos Central Firewall Management. A suitable additional subscription is required.
• RMA and support: Advance Hardware Replacement requires Enhanced Plus Support on the Primary of an Active-Passive hardware cluster. In Active-Active, each device requires either Enhanced Support or Enhanced Plus Support.

Manage the HA pair in Sophos Fusion

An HA pair can be connected to access-layer switches, including Sophos Switches. Sophos Fusion, formerly Sophos Central, provides centralised management of the firewalls and Sophos Switches. This does not replace a redundant switch design: a shared switch can still affect both nodes. The older SFOS 23 overview still uses the name Sophos Central; this does not imply a different HA architecture.

An established HA pair is managed in Sophos Fusion as one pair, not as two independent firewalls. Both nodes need the same firmware version and, for Central Management, working IPv4 internet access and the appropriate subscription. Claiming and licence synchronisation alone don’t enable management.

When two firewalls already managed individually in Sophos Fusion are combined into an HA pair, Sophos recommends deregistering both first. Establish HA locally, register the completed pair for Central Management again, and move it to another Central group if required.

On the current Primary, go to System > Sophos Central and select Register both HA devices. Then enable Central Management and, in Sophos Fusion under My Products > Firewall Management > Firewalls, open Approval Pending for the Primary and confirm accept-services. After a few minutes, the pair should appear once with an HA icon; changes from Sophos Fusion then apply to both firewalls.

The Central status doesn’t replace local validation. After registration, check HA roles, synchronisation, licence status and a harmless configuration comparison locally. If two independent entries appear or Approval Pending remains, don’t deregister either firewall as a precaution. First compare serial numbers, Central tenant, IPv4 path and local HA status.

The Initial Primary is particularly important in Active-Passive because this device holds the licence for the cluster. The HA view indicates which device holds the cluster licence. Record the device unambiguously in the operations manual.

Licence on the wrong firewall – Active-Passive only: If Active-Passive subscriptions were mistakenly assigned to the Auxiliary instead of the licence-holding Initial Primary, synchronisation isn’t sufficient. Before making any changes, document the mistakenly licensed Auxiliary’s source serial number and the intended Initial Primary destination serial number separately from the current HA roles, and cross-check them in SFOS and Sophos Fusion. This abbreviated correction procedure applies only when the current Primary and Initial Primary are the same physical device. If they are different devices or the mapping is unclear, stop before disabling HA or transferring licences and clarify the applicable procedure using Sophos guidance or with Sophos Support; do not improvise a role switchback. Only once the mapping is unambiguous, disable HA on the current Primary in a planned change, transfer the subscriptions in Sophos Fusion from the documented source serial number to the documented Initial Primary destination serial number, and then configure the Active-Passive cluster again. Licence transfers are also relevant to RMA or model changes, but require the applicable procedure for the specific case. Because HA models must match, both devices must be replaced when changing models. In Active-Active, the Auxiliary must also hold its own licences. This is not an error and must not be corrected with this transfer. Do not reuse this Active-Passive procedure for Active-Active RMA without applicable Sophos guidance.

Expired or unsynchronised Active-Active licences can stop load balancing and disable HA. For hardware and Virtual/Software, Sophos describes the onset of the load-balancing stop inconsistently: the summary places it at the end of three days, while the detailed points place it within the first three days and HA deactivation afterwards. The exact onset remains unresolved; this is not a guaranteed three-day grace period. Correct licence problems promptly and, if needed, agree a safe operating plan for the installed build with Sophos Support. Active-Active is not activated during initial setup when licences do not match.

In Active-Passive, synchronise the Primary’s licences. The licence-holding Initial Primary must synchronise them at least once every 90 days. On hardware, the affected protection subscriptions otherwise stop, while Base Firewall and Enhanced Support remain active. On Virtual/Software, the Base Firewall licence is deactivated, HA is disabled and additional protection functions become inactive. Online-licensed clusters therefore require DNS, correct system time, routing and internet access to the Sophos licensing services. Isolated clusters use the documented manual Air-Gap licensing workflow instead.

In Active-Active, on hardware and Virtual/Software, synchronise each device’s licences individually with Sophos Fusion and verify success on both Primary and Auxiliary. Matching licence types and possession of licences do not replace this step. On hardware, Base Firewall and Enhanced Support remain active during the described licence problems; on Virtual/Software, a deactivated Base Firewall licence disables HA and makes the other licences inactive. Do not use an unresolved three-day statement as a synchronisation interval.

At minimum, document:

• Which device is the Initial Primary
• Which serial numbers or appliance IDs belong to the cluster
• Which licences are active on which device
• When the licences were last successfully synchronised; in Active-Active, record the status and time separately for both nodes
• Which support level is available for RMA or Advance Replacement
• Who approves licence changes, renewals and RMA processes

Network Prerequisites

• HA link: Dedicated connection between the firewalls, ideally directly with an Ethernet cable.
• HA link zone: DMZ zone with SSH enabled for the zone.
• HA link IP addresses: Static IP addresses in the same subnet, but different addresses.
• HA link quality: High bandwidth, low latency and no packet loss.
• Switches: Enable RSTP on switches connected to firewall ports.
• Monitored Ports: Monitor only ports that are connected and critical.
• Cellular WAN: Disable for HA.
• Peer Admin Port: Plan separately so that the Auxiliary Firewall remains reachable.
• Interface addresses: Active-Active requires static IP addresses on all interfaces. Active-Passive permits DHCP, DHCP prefix delegation or PPPoE. The PPPoE connection does not have session failover.

In Active-Passive, production interfaces can use DHCP, DHCP Prefix Delegation or PPPoE, but the Dedicated HA Link and both administration ports still require static addresses. In Active-Active, all interfaces must have static addresses. The documented PPPoE limitation does not establish a blanket DHCP-interface session exception: address assignment and DHCP protocol traffic are distinct from preservation of forwarded TCP sessions. Apply the protocol and service failover limits above; DHCP support alone does not guarantee uninterrupted sessions.

Configure breakout interfaces on the Primary. For a new breakout configuration, restart the Primary first to apply the change, then restart the Auxiliary. If the matching breakout configuration already exists on the Primary, restart only the Auxiliary after synchronisation. If the Primary has no corresponding breakout configuration, synchronisation deletes a breakout configuration that exists only on the Auxiliary. Configure breakout interfaces explains the individual cases.

The HA link carries no normal client or server traffic. It is used only for heartbeats, status, session synchronisation, configuration synchronisation and Active-Active distribution. It can’t be reused for HSRP because HSRP hello messages don’t traverse the dedicated HA link. Nevertheless, it is extremely critical. If the HA link fails, both firewalls can believe they are Primary. This split-brain scenario must be avoided.

The Peer Admin Port provides separate operational access to the Auxiliary Firewall. QuickHA automatically selects the interface carrying the current WebAdmin session, and access to the Auxiliary through its Peer Admin address requires a client in the same subnet. Conflicting official management-address instructions: The HA modes and roles documentation excludes both the Dedicated HA Link and administration ports from synchronisation, and the HA-specific interface requirements specify different static IP addresses for both administration ports in the same subnet. In contrast, the startup management-port guide forbids different PortMGMT IP addresses in HA because it says the configuration is synchronised. These instructions contradict each other; a shared PortMGMT IP plus an additional peer IP is not an established reconciliation. Before setup or management-address changes, document the current Primary/Auxiliary roles (or intended roles for standalone devices), exact installed SFOS build, selected administration interface and current IP addresses. Secure a backup and a separate console or local administrative path, then verify the applicable address behaviour for the installed build using Sophos guidance or ask Sophos Support. If the conflict remains unresolved, stop before selecting Initiate HA or changing management addresses.

The default address for regular ports is 172.16.16.16; the dedicated PortMGMT on larger appliances uses 10.0.1.1. The Primary is reachable from any zone where HTTPS is allowed under Administration > Device access. To reach WebAdmin on the Auxiliary, the administration endpoint must be in the same subnet as its administration port.

Ports and Interfaces

• Dedicated HA link: Carries heartbeats, status, configuration and session synchronisation. Connect it directly or through a highly reliable switch. Do not use it for production traffic.
• Monitored ports: Monitor critical production links. Monitor WAN, important DMZ or core uplinks, but do not select unused ports.
• Peer Admin Port: Provides access to the Auxiliary WebAdmin. Plan and document it separately; the client must be in the appropriate subnet.
• Production interfaces: Cable LAN, WAN, DMZ, VLANs and LAGs identically on both firewalls and design them equivalently.

Physical interfaces, VLANs or LAGs can serve as the Dedicated HA link. Bridge interfaces and alias IP addresses cannot be used as the dedicated HA link. QuickHA can combine up to four unbound physical interfaces into an HA redundant link; for an existing LAG, the parent interfaces must be arranged identically on both appliances.

For SFOS 23, a Dedicated HA link using a LAG or VLAN over LAG requires Keepalive request interval × Keepalive attempts ≥ 2500 ms. The SFOS 23 setup default of 100 ms × 3 = 300 ms does not meet this LAG requirement and must not be applied unchanged here. A permitted example is 250 ms × 10 attempts = 2500 ms, not a universal default. QuickHA creates an HA redundant link as a LAG when more than one unbound physical interface is selected, so this requirement also applies to that topology; verify the actual link configuration. Do not assume that QuickHA automatically negotiates suitable values; verify the configured values before relying on the cluster.

High-speed ports: For 25, 50 and 100 GbE ports on XGS 7500/8500 Series devices, select the same Link mode with matching speed and duplex on both sides under Network > Interfaces > Advanced settings, then select Save. Next, reopen the interface for editing, use Show recommended settings > Load recommended configuration for negotiation and Forward Error Correction (FEC), and select Save again. If the recommendations remain empty after the first save and reopening the interface, disable Auto-negotiation for Media Type and FEC, and save the change. For other ports, use Automatic or identical speed and duplex values, and keep MTU and MSS at their defaults. When QuickHA selects an unbound interface, SFOS resets its Advanced settings; check these values again after HA is established.

Important: The Dedicated HA link and a Monitored Port must not be the same interface. If an interface already used by production configuration is selected as the HA link, the firewall can change or remove dependent interface configuration. The HA link should therefore be free and documented in advance.

Network Design

Both firewalls must be able to take the same network position during a failure. Production interfaces, VLAN trunks, LAGs, switch ports and provider connections must therefore be cabled equivalently on both sides. WAN redundancy, SD-WAN and provider failover remain separate tasks; HA does not replace them.

• Connect the Dedicated HA link as directly as possible. If it traverses switches, the path must be stable, low-latency and free of packet loss.
• Geographically separated HA nodes are sensible only across a low-latency Layer 2 network in the same broadcast domain. The Dedicated HA Link remains in the same IP subnet; high latency or packet loss makes this design unsuitable.
• Enable RSTP on the participating switches and configure VLANs, trunks and LAGs identically on both sides.
• Monitor only permanently connected WAN, core or DMZ uplinks. An intentionally disconnected Monitored Port would otherwise trigger failover.
• VLANs and LAGs are supported, but must use the same parent interfaces on both nodes. Bridge Mode works, but is more complex to troubleshoot than Gateway Mode.
• Test VPN, RED and remote scenarios separately because not every session transfers transparently.
• Deliberately restrict management access and Device Access. See Securing Sophos Firewall Access: Configuring Device Access Correctly.

For Active-Active, it must also be clear which bottleneck the traffic eligible for TCP distribution will relieve. If licensing, services and troubleshooting on both nodes are not settled, Active-Passive remains the better choice.

Warning: In a split-brain situation, both firewalls consider themselves responsible. This can cause duplicate IP and MAC use and a production outage. If the HA link fails, first decide which node should remain active and shut down the other node in a controlled manner or disconnect it from the production network.

Prepare the Setup

Do not improvise in the production network before setting up HA. This preparation saves considerable time later.

Prepare Both Firewalls

• Bring both firewalls to the same SFOS version, including build.
• Check licence and registration status.
• Disable Cellular WAN.
• Confirm that the models are compatible.
• Check the Flexi Port configuration.
• Document interfaces and switch ports.
• Select the HA link port.
• Connect the HA link directly or check the switch path.
• Plan the DMZ zone and SSH access for the HA link.
• Document administrative access to both devices.
• Create a backup of the existing configuration.
• If LINCE is required, align the mode on both devices before enabling HA.

FIPS follows a different sequence from LINCE. Enable FIPS 140-3 on the standalone primary first, which performs a factory reset; Sophos automatically enables FIPS on the auxiliary during the subsequent HA setup.

Backups are not optional with HA. A backup should be available before setup, firmware updates and major interface changes. See Creating or Restoring a Sophos Firewall Backup.

Before selecting Initiate HA, also check:

• Management-address conflict resolved: Record current or intended Primary/Auxiliary roles, exact installed SFOS build, selected administration interface and current IPs; secure a backup and a separate console or local administrative path. Verify the applicable address behaviour for that build using Sophos guidance or Sophos Support. If unresolved, stop before Initiate HA or management-address changes.
• Dedicated HA link without production dependencies: HA can change interface IP addresses and dependent configuration.
• Monitored Ports connected on both devices: A disconnected Monitored Port can prevent the cluster from forming or trigger immediate failover.
• Unique Cluster ID: Multiple HA clusters in the same Layer 2 area require different virtual MAC addresses.
• Backup, SSMK and firmware build documented: The cluster must be reproducible during restore, RMA or reimage.

Set LINCE Before HA

Since SFOS 21.5 MR1, LINCE cannot be enabled or disabled after an HA cluster has been established. If certification is required, run the following command in the Device Console on both standalone firewalls.

Warning: First ensure that WebAdmin or local console access is available as an alternative administrative path. The command enables LINCE, restarts the SSH service, and disconnects existing SSH sessions.

system certification lince enable

Then verify the LINCE status on both devices before establishing HA. During a restore, the backup and target cluster must have the same LINCE status.

Understand and enable LINCE mode on Sophos Firewall explains why the mode doesn’t automatically certify the deployed SFOS build and which SSH algorithms must be checked before activation.

QuickHA or Interactive Mode

• QuickHA: The standard case. Fast, robust and sufficient for most Active-Passive and Active-Active deployments.
• Interactive mode: Useful when Admin Ports, HA link addresses, Cluster ID, Monitored Ports and detailed values must be specified before the cluster is established.

QuickHA initially asks only for the role, node name, passphrase and Dedicated HA link. The passphrase must be 10 to 20 characters long and contain at least one uppercase letter, one lowercase letter, one number and one special character. It is used once to generate the SSH keys and is then deleted. Before replacing a device in a still-functioning HA pair, HA must therefore be disabled and then configured again with the replacement device. The relevant sections below explain the distinct starting state after RMA and the differing reimage descriptions.

Prepared QuickHA devices continue looking for their peer until they find it. They can therefore be configured in advance and connected later at the destination. Once a device has discovered the peer and HA establishment is in progress, this discovery process can’t be stopped. Interface selection, passphrase and intended peer must therefore be correct before both HA links are reachable at the same time.

The steps below follow the official Sophos HA configuration but are deliberately written as a practical admin checklist. For production changes, do not simply click through the wizard; document roles, HA link, administrative access, backup, licence status and rollback path in advance.

Node names in QuickHA: In SFOS 22, assigning a name is optional. For SFOS 23, the detailed guides require a node name, while the example guides still describe it as optional. The following checklist therefore assigns different, easily recognisable names to both devices. This is conservative guidance, not evidence that the GUI rejects an empty name field.

Set Up HA

Active-Passive with QuickHA

1. Prepare the Primary Firewall

1. Sign in to WebAdmin on the firewall that will become the Primary.
2. Go to System services > High availability.
3. Select Primary (active-passive) as the mode.
4. Use QuickHA.
5. Assign a unique node name, for example FW01.
6. Set an HA passphrase of 10 to 20 characters containing an uppercase letter, a lowercase letter, a number and a special character.
7. Store the passphrase securely for the moment because it is required on the Auxiliary Firewall next.
8. Select the Dedicated HA link.
9. Select Initiate HA.

Notes:

• When QuickHA uses an unbound interface, Sophos assigns the DMZ zone and 169.254.192.1 to it by default. SSH is enabled automatically for the zone.
• The firewall removes dependent configuration from the selected HA link interface. It must therefore be free of production dependencies.

2. Prepare the Auxiliary Firewall

1. Sign in to the firewall that will become the Auxiliary.
2. Go to System services > High availability.
3. Select Auxiliary as the role.
4. Use QuickHA.
5. Assign a different node name from the Primary, for example FW02.
6. Enter the same HA passphrase.
7. Select the same HA link port as on the Primary.
8. Select Initiate HA.

After the cluster is established, the Primary Firewall synchronises the configuration to the Auxiliary Firewall. Many local settings on the Auxiliary Firewall are overwritten. The Auxiliary should therefore not be configured in parallel as a standalone production firewall before HA setup.

3. Check Advanced Settings

After the cluster is established, check the following points instead of simply leaving the page:

• HA status of both nodes
• Role and status at the top right of WebAdmin
• Dedicated HA link
• Monitored Ports
• Peer Admin Port
• Preferred primary
• Keepalive interval and Attempts
• Licence holder in Active-Passive
• Sophos Fusion registration, if used

4. Set Monitored Ports

Monitored Ports determine whether an interface failure triggers failover. The selection field is called Select ports to be monitored in SFOS 22 and Monitored interfaces in the detailed SFOS 23 guides. Typical candidates:

• WAN uplink
• Core LAN uplink
• Important DMZ or server uplinks

Do not monitor ports that are intentionally offline at times, are not cabled or are used only for optional scenarios. An incorrectly selected Monitored Port is a common cause of unexpected failover or a cluster that does not start.

Eligible choices are physical interfaces, LAGs and unbound interfaces with a configured VLAN. An unbound interface without a VLAN can’t be selected as a Monitored Port. Monitored Ports require static IP addresses in both HA modes.

SFOS 23 allows a maximum of 24 Monitored ports. Keep the selection distinct from the Dedicated HA link and include only genuinely required production links.

HA also works without any Monitored Ports selected. In that case, a production port failure alone does not trigger failover; heartbeat, device or power failures can still trigger a role change. Every port actually selected must be connected on both nodes. Port status monitoring does not detect every upstream provider outage.

Advanced HA settings such as Monitored interfaces, Peer administration, Preferred primary and keepalive values are changed on the current Primary after QuickHA is established. First check that a backup, a maintenance window and reliable administrative access are in place; the MAC change described above causes downtime. Before changing Peer administration or management addresses, repeat the management-address conflict preflight above; if unresolved, stop before making changes or selecting Initiate HA. For a LAG-based HA link, observe the keepalive requirement and do not change values while the status is Standalone or Faulty. After making the required selections, scroll back to the top of the page and select Initiate HA. The Primary then synchronises the changes to the Auxiliary. Afterwards, check HA roles, status, synchronisation and the changed values on both nodes; if there are discrepancies, first compare the HA link and logs on both devices. This completion step also applies to the Active-Active variant below and is distinct from the initial joining of the two devices.

Active-Active with QuickHA

Active-Active is configured similarly, but for a different objective. Both firewalls must be licensed appropriately beforehand.

The process is the same as for Active-Passive, but select Primary (active-active) on FW01. Both devices must first be claimed, run the same SFOS build and have matching licence types; all interfaces require static IP addresses. Monitoring and troubleshooting must cover both nodes, and the relevant traffic must benefit from the TCP distribution described above.

Test After Setup

Active-Active requires more testing than checking the HA status alone:

• Are connections distributed across both nodes?
• Have both nodes’ licences been successfully synchronised individually, with status and time recorded separately?
• Are logs visible on both devices?
• Do VPN connections work after a role change?
• Do Web Protection, IPS, Application Control and the relevant security features work?
• Do any applications show problems caused by asymmetric behaviour?
• Are reports and alerts generated as expected?

Interactive Mode

Interactive mode is useful when the automatic QuickHA logic does not provide enough control.

Before configuration, allow SSH and Ping/Ping6 for the DMZ zone on both devices under Administration > Device access. Interactive mode initially selects the first DMZ interface automatically as the Dedicated HA link. If that interface isn’t intended for HA or has production dependencies, select a free physical, VLAN or prepared LAG interface before saving.

Typical reasons:

• Fixed HA link IP addresses are required
• The Peer Admin Port must be defined precisely
• The Cluster ID must be set deliberately
• Multiple HA clusters exist in the same Layer 2 environment
• Virtual appliances require specific MAC options
• A highly controlled rollout is required

In Interactive mode, configure the Auxiliary first and the Primary afterwards. This prevents peer detection on the Primary from timing out while the second node is still being prepared.

1. Configure the Auxiliary

1. On FW02, go to System services > High availability.
2. Select Initial device role > Auxiliary and HA configuration mode > Interactive mode.
3. Set the node name and a passphrase that follows the rules above.
4. Select the unused DMZ port for the Dedicated HA link. The firewall removes existing dependent configuration from this interface.
5. Save and wait for confirmation that the Auxiliary configuration has been applied.

2. Configure the Primary

1. On FW01, select Primary (active-passive) or Primary (active-active) and Interactive mode.
2. Set a unique Cluster ID and the node name.
3. Enter the passphrase from FW02.
4. Specify the same Dedicated HA link and the Auxiliary’s static HA link IP address. The field is called Dedicated peer HA link IPv4 address in SFOS 22 and Peer IPv4 address of dedicated HA link in the detailed SFOS 23 guides. Both HA link addresses must be in the same subnet. This is the HA link IP, not the peer administration IP under Peer administration settings; verify the management-address behaviour as described above.
5. Select the critical Monitored ports; SFOS 23 allows at most 24.
6. Under Peer administration settings, specify the management interface and peer administration IP address for FW02 only after completing the management-address conflict preflight above and verifying the applicable address behaviour for the installed build. If unresolved, stop before entering changes or selecting Initiate HA.
7. If required, select Use host or hypervisor-assigned MAC address for virtual appliances in SFOS 22, or Use interface MAC address in SFOS 23. The SFOS 23 option uses the hypervisor-assigned MAC on virtual appliances and the interface MAC on hardware instead of the cluster virtual MAC. Turning it on or off causes downtime.
8. Set the Preferred primary and select Initiate HA.

After setup, change the keepalive values only for a documented reason. SFOS 22 permits intervals of 250–500 ms and 16–24 attempts; its defaults of 250 ms and 16 attempts give a 4-second timeout. SFOS 23 permits 100–500 ms and 3–24 attempts; its defaults of 100 ms and 3 attempts give a 300 ms timeout. For SFOS 23 Dedicated HA links using LAG or VLAN over LAG, the product must be at least 2500 ms: 250 ms × 10 attempts is a permitted example, not the general default. Check this also for QuickHA-created redundant LAGs. These values can’t be changed while the devices have Standalone or Faulty status. After the timeout, the new Primary performs internal checks before it starts processing traffic. Neither timeout guarantees a traffic-recovery duration.

API discrepancy in SFOS 22: The description of Keepalive attempts specifies 8–16 attempts, whereas the detailed parameter constraint and XML sample specify 16–24. The range stated here follows the detailed constraint, not a tested API result; 8–16 is not a second confirmed range. Before making changes, document the installed SFOS build and the current keepalive values on both nodes. If the applicable limits remain unclear, clarify them with Sophos Support before making a change; the LAG requirements must still be observed.

API preflight check for SFOS 22 and 23: The parameter tables document ClusterId as an optional integer from 0–63 with a default of 0, and NodeName as a mandatory string of 1–30 characters. Even with the documented default, each cluster on the shared Layer 2 network must use a distinct Cluster ID to avoid virtual MAC conflicts. These API metadata do not change the GUI guidance above on optional or required naming, nor do they establish GUI validation. The table uses ClusterId, while the XML sample uses ClusterID; this establishes neither a tested tag mapping nor a working API payload.

In SFOS 23 advanced HA settings, Monitor hardware components is optional and adds a failover trigger when a storage-device issue is detected, alongside heartbeat failure detection and monitored-interface failures. Do not assume it is enabled by default or that it detects every hardware fault.

SFOS 23 API note: The API parameter table lists HardwareMonitor as an optional scalar parameter (SCALAR, Mandatory: No), with values Enable and Disable and a documented API default of Enable. That documentation value establishes neither the actual GUI setting nor the device’s runtime state. Check the setting on the installed device; the storage-device scope described above remains unchanged.

The SFOS 23 API XML sample still contains Number(250-500) and Number(16-24). These placeholders disagree with the table ranges of 100–500 ms and 3–24 attempts and must not be copied as complete limits. This establishes neither product rejection of the lower values nor tested API behaviour.

Connect a new virtual Auxiliary as an HA spare

For a new virtual Auxiliary in Active-Passive, the setup assistant can use Connect as HA spare. This procedure is an alternative to the Auxiliary-first setup described above for two existing devices: the new spare VM is not configured as an Auxiliary beforehand. Complete the management-address conflict preflight above before selecting Initiate HA; automatic administration-port configuration does not resolve the conflicting address instructions. Active-Active or two existing Virtual/Software firewalls still require QuickHA or Interactive mode on both devices.

1. On the existing Primary, allow DMZ SSH under Administration > Device access and select Primary (active-passive) and Interactive mode under System services > High availability. In SFOS 23, enter a Cluster ID and a node name before selecting Initiate HA; the SFOS 22 guide describes entering the Cluster ID and changing the node name as optional. If multiple HA clusters share the same Layer 2 network, use a distinct Cluster ID for each cluster to prevent virtual MAC address conflicts. Securely record the Dedicated HA Link, its own IP address and subnet mask, the intended peer IP, Peer Administration and the HA passphrase used on the Primary. Then select Initiate HA; in SFOS 23, scroll back to the top of the page to do so. At this point, before the new VM joins, the Sophos spare guide documents the message HA could not be enabled and a temporary Standalone status. Neither alone establishes that a completed cluster has failed during this setup stage.
2. Install the new virtual firewall with exactly the same SFOS build, start the setup assistant, and set a new administrator password.
3. Select Connect as HA spare and enter the existing Primary serial number, the same HA passphrase previously used on the Primary and securely recorded, and the same Dedicated HA Link interface. For the new spare, use its own free IP address, different from the Primary’s, in the subnet of the existing Primary Dedicated HA Link with the identical subnet mask; it must match the peer IP prepared there. Do not assume a passphrase from a supposedly already configured Auxiliary.
4. Select Apply, Continue, and Finish. SFOS creates the Auxiliary, assigns a serial number beginning with HAAUX, and automatically configures the Dedicated HA Link and administration port.
5. After a few minutes, refresh Auxiliary WebAdmin and sign in again. Then verify roles, synchronisation, Peer Admin, Monitored Ports, and failover on the Primary.

Validate the Cluster

After setup, validate the HA cluster systematically.

WebAdmin Check

1. Sign in to the Primary Firewall.
2. Check the HA status at the top right.
3. Go to System services > High availability.
4. Check roles, status, serial numbers and mode.
5. Confirm that the cluster is synchronised.
6. In Active-Passive, check which device holds the cluster licence.

CLI Check

In the Device Console, the following read-only command displays roles, status and cluster synchronisation. It does not change the configuration:

system ha show details

Check SFOS 22 operational parameters

SFOS 22 publishes two additional HA controls. Read both before making any change:

system ha auxiliary_system_traffic_through_dedicated_link show
system ha load-balancing show

The first control determines the path for system traffic sent by the Auxiliary Firewall itself. By default, all of this traffic passes over the Dedicated HA Link. In addition to all, the options are none and only_dynamic_interface. Sophos does not define more precisely which flows qualify as a dynamic interface in the last mode. Use that option only for a use case confirmed for the installed build, not as a general routing fix.

The second control turns distribution of eligible traffic between the firewalls on or off. It neither replaces selection of the HA mode nor makes the services and tunnels excluded above eligible for load balancing. Make changes individually in a maintenance window and save both show outputs first:

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

Then verify roles, synchronization, the Dedicated HA Link, new sessions, node-local logs, and system connections initiated by the Auxiliary itself. For rollback, restore the previously observed value. Sophos documents all as the default only for the first control; do not assume a default for load balancing.

Check which device is the licence-holding Initial Primary under System services > High availability. Sophos also documents the following official CLI check in the Advanced Shell:

nvram get "#li.master"

YES identifies the Initial Primary that holds the cluster licences; NO identifies the device configured as Auxiliary. The command is read-only. The HA view remains easier for daily checks, but the shell output is also officially documented.

If shell access has not yet been prepared, see Connecting to Sophos Firewall via SSH.

Functional Test

• Test internet access from a LAN client.
• Test access to internal servers.
• Test VPN.
• Test DNAT or WAF scenarios.
• Test DNS and DHCP if the firewall provides these services.
• Check logs in Log Viewer.
• Test an HA role change during a maintenance window.
• Document roles, status and session behaviour afterwards.

Operation and Maintenance

Ongoing Monitoring

Monitor HA and role status, the Dedicated HA link, Monitored Ports, licences, firmware, CPU, RAM, disk and central services. Send alerts to Sophos Fusion, email or the existing monitoring platform.

Consider both nodes separately for disk and hardware topics. Local reports, log files and SSD health can differ. See Checking Sophos Firewall Storage and Managing Reports and Checking Sophos Firewall SSD Health with SMART.

Logs and Reports

Each node writes logs for the traffic it processes. In Active-Active, both devices must therefore be checked. Sophos Central Firewall Reporting or syslog is suitable for consolidated analysis. Local files are explained in Sophos Firewall Troubleshooting: Services and Logs.

The Auxiliary sends report emails only for reports that contain data on that node, such as email activity or pattern updates. It doesn’t send reports without data, such as Security Dashboard or Security Audit. A missing email for these report types therefore isn’t evidence of a fault by itself.

In Active-Active, the source IP provides an initial indication of the expected logging node: for eligible TCP traffic, even-numbered addresses belong to the Primary and odd-numbered addresses to the Auxiliary. This does not apply universally to the traffic types excluded above and does not replace comparing both devices, especially after a role change.

For HA events, open Log viewer > System separately on each node. Use Add filter to select the appropriate filter and value for the affected period, then apply it with the Add filter button. For detailed analysis, open Diagnostics > Tools > Troubleshooting logs > Select files on both devices and select csc.log for the central service that manages the other services. Also select the HA files described below under Important Logs and Diagnostic Locations, and save each package separately with Download. To reconstruct the sequence of cluster events, compare the records from both nodes and check for gaps in time coverage or rotated logs.

Runbook for HA Operation

Document at least the following in the operations runbook:

• Serial number, location, rack position and role of both appliances.
• Dedicated HA link, Peer Admin Port, Cluster ID and Monitored Ports.
• Preferred primary and expected behaviour after failover.
• Licence holder, support status and RMA contact path.
• Process and responsibility for firmware updates, backup, reimage, hardware replacement, logs and support cases.

If WebAdmin is unresponsive on only one node, the entire HA cluster is not automatically defective. First check whether restarting the WebAdmin GUI or a controlled service restart is sufficient before triggering failover or a reboot.

Changes to the Cluster

Change rules, interfaces and policies only on the Primary. Before changing interfaces, VLANs, LAGs, zones, routing, NAT, VPN, Device Access or SD-WAN:

• Create a backup.
• Define a maintenance window.
• Check HA status.
• Update the documentation.
• Define a rollback path.
• Then test synchronisation and traffic.

Manual synchronisation and forced role change

Automatic synchronisation is the normal operation. Use Sync auxiliary device on the Primary or Auxiliary only to resolve a confirmed synchronisation problem. The Auxiliary restarts, performs a full synchronisation of the database and related files, and remains the Auxiliary. Logs and reports remain local to each node. The firewall drops all masqueraded connections during this process, so schedule it in a maintenance window.

In Active-Passive, force the Auxiliary to take over with Switch to passive device on the current Primary or Switch to active device on the current Auxiliary. The current Primary restarts. This is a planned role change with session risk, not a harmless toggle.

Disable HA deliberately

The Sophos HA FAQs for SFOS 22 and 23 state a general prerequisite: disable HA before reimaging, before replacing a node in an HA pair and before transferring a licence between nodes. The one-time passphrase for the SSH tunnel is deleted after the tunnel is established; HA must therefore be disabled and configured again for a new device. This requirement does not replace case-specific planning: the reimage details below contain a discrepancy in the documentation, and the RMA procedures assume that a healthy node is already in the Standalone HA state. Plan the backup, reliable administrative access, maintenance window and rebuild beforehand; for the Active-Passive licence correction, also meet the serial-number and role condition described above.

Whenever possible, disable HA on the current Primary under System services > High availability > Disable HA. The node used determines the outcome:

Fusion access from SFOS 22 MR1 onwards: The Sophos Known Issues, NC-186855, describe an exception to the general behaviour above: disabling HA in the firewall interface opened through Sophos Fusion/Central using FRP-SSO can leave the Auxiliary as a standalone device with HA still enabled, while HA is already disabled on the Primary. This creates a split-brain risk. After the action, check the HA state on both devices separately. If their states are inconsistent, pause the planned rebuild and coordinate recovery with Sophos Support before operating the devices as a pair again. A successful dialogue on the Primary is not a sufficient check. As of 24 October 2026, the entry lists no fixed version.

Firmware Updates and Backups

Firmware Updates in HA Environments

Firmware updates are started on the Primary Firewall. The devices are updated in sequence, and the cluster can change roles during the process.

Typical process:

1. Start the update on the Primary Firewall.
2. The Auxiliary Firewall is updated.
3. The Auxiliary Firewall restarts and temporarily takes over.
4. The former Primary is updated.
5. The former Primary restarts.
6. If Preferred primary is enabled, the role can switch back to the preferred device.

Nevertheless, firmware updates belong in a maintenance window. Even though the process is designed for minimal downtime, individual sessions, VPN connections or special applications may be briefly interrupted or require reconnection.

A firmware rollback of the HA pair follows the same process and doesn’t require disabling HA first.

See Sophos Firewall Firmware Update: Preparation and Best Practices.

Pattern Updates

Pattern updates are installed on the Primary and synchronised automatically to the Auxiliary. This also applies to environments in which updates are controlled or installed offline.

In an isolated HA environment, clarify which node is the Initial Primary and which is currently Primary before each manual pattern or licence update. The Air-Gap procedure is described in Operating Sophos Firewall Air-Gap Licensing and Pattern Updates.

Backup and Restore

Create backups regularly and before every major change. If LINCE is enabled, the backup and target cluster must have the same LINCE status. Three different restore cases apply:

Caution when the backup has no HA: The Sophos descriptions for SFOS 22 and 23 contradict themselves about the Auxiliary’s state after this restore: the prose says it retains its previous configuration, while the summary says it is factory-reset except for the Peer Admin Port and Dedicated HA Link. Neither full retention nor a factory reset is therefore established behaviour. Do not rely on the Auxiliary’s configuration being preserved. First save the configurations externally, record administration IP addresses and credentials, and plan downtime and an HA rebuild. Before depending on the uncertain Auxiliary state, clarify the procedure for the installed SFOS build with Sophos Support.

If the Primary was registered as a Sophos ZTNA gateway, add it as a gateway in Sophos ZTNA again after restoring to the HA cluster.

Reimage HA nodes in Active-Passive

A reimage interrupts operation and, according to Sophos, applies only to Active-Passive. First run system diagnostics show version-info in the Device Console on both nodes, document the firmware including build and the Initial Primary, and save a current backup externally.

Scope of the following procedures: At the outset, FW1 is both the current Primary and the licence-holding Initial Primary; FW2 is the current Auxiliary. These names identify the same physical devices throughout the entire procedure, including after a role change. The intended final state is again FW1 as Primary and FW2 as Auxiliary. If the current Primary and Initial Primary are different devices, do not improvise using these procedures: first establish the roles and licence holder using the applicable Sophos guidance or with Sophos Support.

Resolve the documentation discrepancy before reimaging: The HA FAQs for SFOS 22 and 23 generally require HA to be disabled before reimaging. However, for reimaging the Primary or both nodes, the detailed Active-Passive guides describe a role change with Switch to passive device followed by reinstallation, without specifying a separate Disable HA step. A role change is not the same as disabling HA; the omission does not establish a generally safe exception. The detailed sequences below are therefore retained as documented procedures that conflict on this point. Before executing them, establish a firm plan for roles, Initial Primary, installed build, backup, downtime and rollback, and clarify the applicable order with Sophos Support if you need to rely on this differing detailed sequence. If the order remains unresolved, stop before changing roles or reinstalling; do not insert a deactivation step into the sequence on your own initiative.

If FW1 is registered for Central Management, deregister it before each of the three procedures. Then, in the same Sophos Central/Fusion tenant under My Products > Firewall Management > Firewalls, check that the entry for FW1 is no longer present. Only then proceed with the backup, HA deactivation or role change. This check applies to registered Firewall Management, not only to Synchronized Security.

Reinstall only the Auxiliary FW2

1. After the deregistration and check described above, save the backup from FW1 externally and disable HA on FW1, never on FW2.
2. In the Advanced Shell on FW1, use service -S | grep msync to check that msync shows UNTOUCHED or STOPPED. Otherwise, do not proceed.
3. Reinstall FW2 with exactly the same firmware version, including build, as FW1. Sign in locally and configure only WAN for internet access, with no LAN or DMZ interfaces configured. Then claim FW2 if it has not already been claimed.
4. Rebuild HA with FW1 as Primary and FW2 as Auxiliary.

Reinstall only the Primary FW1

1. After deregistration and the check, save the backup from FW1 externally and use Switch to passive device to let FW2 take over. The device identities remain unchanged.
2. Reinstall FW1 with exactly the same firmware version, including build, as FW2. Sign in locally, configure only WAN for internet access, with no LAN or DMZ interfaces configured, and claim FW1 if it has not already been claimed.
3. For the restore, disconnect every cable from FW1 except the administration PC, restore the backup, reconnect the cables, and return traffic from FW2 to FW1.
4. Then reset FW2 to factory settings. Sign in locally, configure only WAN for internet access, with no LAN or DMZ interfaces configured, and claim it if it has not already been claimed.
5. Rebuild HA with FW1 as Primary and FW2 as Auxiliary.

Reinstall and upgrade both nodes

1. Perform the deregistration, check, backup and role change as for the Primary reimage. However, install the target version, including the target build, on FW1. Then sign in locally, configure only WAN for internet access, with no LAN or DMZ interfaces configured, and claim it if it has not already been claimed.
2. For the restore, disconnect every cable from FW1 except the administration PC, restore the backup there, reconnect the cables, and return traffic from FW2 to FW1.
3. Unlike a Primary-only reimage, do not merely reset FW2 to factory settings at this point: reinstall it with exactly the same target version, including build, as FW1. Sign in locally, configure only WAN for internet access, with no LAN or DMZ interfaces configured, and claim it if it has not already been claimed.
4. Rebuild the Active-Passive cluster with FW1 as Primary and FW2 as Auxiliary. The planned interruption also includes this second reinstallation and joining step.

If the cluster uses Sophos Fusion Synchronized Security, remove the HA pair from Central management before returning the device through the RMA process. After replacement, register the new HA cluster in Central again. This prevents serial number and license synchronization conflicts with the old device that remains registered.

Replace the Auxiliary After RMA

Replacing or reimaging a node causes a planned interruption. The following procedures apply to Active-Passive; for Active-Active, plan the specific procedure with Sophos Support. Both detailed RMA variants assume that the remaining healthy node is already operating as Standalone HA: the healthy Primary for an Auxiliary RMA, and the healthy Auxiliary for a Primary RMA. Only for this starting state do the sources describe claiming the replacement device and transferring its licence before subsequently disabling HA or resetting the healthy node, respectively. Do not apply this order to replacement in a still-functioning HA pair; the FAQs’ general requirement to disable HA beforehand applies there. If the starting state does not match or is unclear, stop before replacement or licence transfer and plan the procedure with Sophos Support.

1. Check that the replacement model and hardware revision are suitable and install exactly the same firmware build as on the healthy Primary.
2. First prepare local access to the replacement device. The documented port example connects a DHCP-capable administration PC to Port 1 and opens https://172.16.16.16:4444; WAN is connected to Port 2 and configured for internet access in the Setup Assistant. If the port layout differs, use the administration and WAN ports appropriate to the device model. Do not configure any other interfaces. Only then claim the replacement device in Sophos Fusion and transfer the licence from the defective Auxiliary device.
3. Move the cables from the defective device to the replacement.
4. On the healthy Primary, disable HA under System services > High availability.
5. In the Advanced Shell, check whether msync has stopped:

service -S | grep msync

The expected state is UNTOUCHED or STOPPED. The command changes nothing; a different state means that HA should not yet be rebuilt. Then reconfigure the healthy Primary as Primary and the replacement device as Auxiliary.

Replace the Primary After RMA

1. Download a current backup from the healthy Auxiliary and deregister the device from Sophos Fusion. In the same Sophos Central/Fusion tenant under My Products > Firewall Management > Firewalls, check that the entry for this healthy Auxiliary is no longer present before proceeding.
2. Bring the replacement device to the same firmware build and sign in locally. In the documented port example, connect a DHCP-capable administration PC to Port 1 and open https://172.16.16.16:4444; configure WAN on Port 2 for internet access in the Setup Assistant. If the port layout differs, use the administration and WAN ports appropriate to the device model. Do not configure any other interfaces. Only then claim it in Sophos Fusion and transfer the licence from the defective Primary.
3. Restore the backup to the replacement device.
4. Move the cables from the healthy Auxiliary to the replacement device. From this point, the replacement processes traffic as a standalone firewall.
5. Reset the former Auxiliary to factory settings and prepare local access again: in the documented port example, connect a DHCP-capable administration PC to Port 1 and open https://172.16.16.16:4444, then configure WAN on Port 2 for internet access in the Setup Assistant. If the port layout differs, use the administration and WAN ports appropriate to the device model. Do not configure any other interfaces. Only then claim it again in Sophos Fusion and connect the intended cables.
6. Rebuild HA with the replacement as Primary and the reset device as Auxiliary.

Warning: Backup/restore, Factory Reset and cable changes cause downtime. Document serial numbers, Initial Primary, firmware build, licence transfer, Central status and rollback path before starting.

For the technical reinstallation, see Reinstalling Sophos Firewall OS: Reimage with a USB Drive. If a hardware defect or RMA process is involved, also plan with Preparing a Sophos Hardware Defect and RMA Correctly.

Troubleshooting

For complex failures, work methodically: check status, HA link, Monitored Ports, firmware version and licence status first, then investigate special cases or vendor guidance. This keeps it clear whether the issue is genuinely related to HA or caused by licensing, an interface, firmware or monitoring.

Important Logs and Diagnostic Locations

• HA status: System services > High availability.
• Event Logs: Log viewer > System.
• Troubleshooting Logs: Diagnostics > Tools > Troubleshooting logs > Select files or through SSH under /log.
• HA details CLI: See the single CLI check under Validate the Cluster.
• Interface problems: show network interfaces, ifconfig, dmesg in appropriate diagnostic cases.
• Licence holder: System services > High availability.

The following files are particularly useful for initial diagnosis:

• ha.log: Setup errors, successful HA establishment and status changes.
• ha_pair.log: Peer discovery in QuickHA.
• ha_tunnel.log: SSH tunnel over the Dedicated HA link.
• msync.log: HA configuration synchronisation.
• ctsyncd.log: Conntrack session synchronisation.
• filesync.log: Service-related file synchronisation, for example for dynamic routes or DHCP.

Each node stores only the logs and reports for the traffic it processes. To access the Auxiliary, sign in through its Peer Admin address or retrieve the log files through SSH on that node.

For deeper analysis, see Sophos Firewall CLI Troubleshooting: Important Commands.

Typical HA Symptoms

• Cluster does not form; firmware version or build differs: Check the version on both devices and bring both firewalls to the identical SFOS version.

• Cluster does not form; model or appliance does not match: Check the model and serial number. For hardware HA, use only compatible identical XGS Appliance models.

• HA could not be enabled: Only for the setup with a new virtual HA spare described above does Sophos document this message immediately after Initiate HA on the Primary, before the spare joins; a temporary Standalone status is also described there. This is not a general reason to disregard the message. If it persists after completing the spare wizard and the waiting/refresh phase, or occurs in another setup, the Dedicated HA link may not be connected or the peer may be unreachable. Ensure that the dedicated HA link interfaces on both devices are connected directly by an Ethernet cable or through the intended switch. On both nodes, check under Network > Interfaces that the selected HA link interface shows Connected. On the Primary, use the ping tool under Diagnostics > Tools to check the Auxiliary’s dedicated HA link IP address, not its Peer Admin address. Replies confirm basic reachability, not completed HA synchronisation. If there are no replies, first check and correct the cable, switch path, link status and HA link IP address/subnet; then repeat the ping and check roles and synchronisation again.

• HA link down: The cable, switch port, VLAN or LAG may be defective. Check interface status, speed/duplex, VLAN trunk and LAG members.

• Both devices become Standalone: The HA link has failed and there is a split-brain risk. Check the physical HA link connection and switch path, shut down one device in a controlled manner, repair the HA link and then restart it.

• Auxiliary WebAdmin unavailable: Peer Admin Port, subnet, route or Device Access do not match. Check the Admin Port IP and access from the management network.

• Validation Failed For Ha interface IP: Search for this exact message in /log/syslog.log on the Primary. Sophos attributes it to administration ports that are not in the same subnet; compare the administration port addresses on both devices. Also check that the HA link addresses are in the same subnet as a separate prerequisite, not as an established cause of this message. Before correcting management addresses, complete the preflight described above to resolve the conflict between the sources: document roles, the installed SFOS build, the administration interface and current IP addresses, secure a backup and separate console or local administrative access, and verify the applicable address behaviour or clarify it with Sophos Support. If the behaviour remains unresolved, stop before changing addresses.

• Unexpected failover: A Monitored Port has often failed or been selected incorrectly. Check Monitored Ports and switch status, then monitor only genuinely critical, stable ports. If the affected node actually rebooted rather than only switching roles, check the unexpected restart specifically for that node.

• Failover does not occur: The relevant port is probably not monitored. Add critical WAN, core or DMZ ports as Monitored Ports.

• Active-Active does not distribute as expected: The traffic type may not be load-balanced. Check connection type, protocol and logs on both nodes; if the benefit is unclear, use Active-Passive or adapt the design.

• Logs appear to be missing: Traffic may have been processed by the other node or logging may be disabled. Check both nodes and Log Viewer, enable logging in the rules and use Central Reporting or syslog.

• Reports differ: Local reports are node-specific. Compare reports from both devices or use Sophos Central Firewall Reporting.

• Licence problem in Active-Active: Licence types may not match. Check Licensing on both firewalls and align the licences.

• Problems after a firmware update: A node may not have updated correctly or the cluster may not be synchronised. Check HA status, firmware versions and logs; use a maintenance window for production clusters and involve Sophos Support.

• Flexi Port HA link fails after an update: On the 1U models XGS 2100, XGS 2300, XGS 3100, XGS 3300, XGS 4300 and XGS 4500, HA may fail to establish when a Flexi Port is used as the Dedicated HA link. After the first device updates and restarts, its Interface speed is no longer set to Auto negotiation, while the second device still uses Auto negotiation.

  Before changing the setting: Record HA roles and port settings on both devices, secure a backup and separate administrative access, and use a maintenance window. If there is split-brain, first follow the HA link failure procedure below: decide which node should remain active and disconnect the other from the production network or shut it down in a controlled manner. Do not restart both nodes without coordination.

  1. On both devices, open Network > Interfaces.
  2. Select the affected Flexi Port interface and open Advanced settings.
  3. Set Interface speed to Auto negotiation.

  Then check link status, HA roles, synchronisation and production traffic. If the problem persists, save settings and logs from both nodes and involve Sophos Support. Restore the recorded previous values only as a controlled change with administrative access secured; doing so may bring the HA link failure back. Alternatively, plan to use a built-in port as the Dedicated HA link—not a fixed speed setting. This change has been checked against documentation, not tested on a device.

WebAdmin and VPN Portal unreachable during certificate synchronisation

The release notes for SFOS 22.0 MR3 Build 576 dated 16 October 2026 list NC-186809 as resolved: certificate synchronisation on the Auxiliary could fail when certain certificate filenames began with two consecutive dots (..), leaving WebAdmin and VPN Portal unreachable. Distinguish this symptom from general routing or Device Access problems, and record the build, affected node, time and available synchronisation logs. Do not rename or delete certificates on suspicion. If this issue is suspected, involve Support and plan a supported firmware change with management access secured; afterwards, recheck both portals and HA synchronisation.

Procedure During an HA Link Failure

If the dedicated HA link fails, proceed carefully. The firewalls can no longer see each other. In the worst case, both devices send ARP/GARP and attempt to claim the cluster MAC.

Safe procedure:

1. Stabilise the network state.
2. Decide which device should remain active.
3. Shut down the other device in a controlled manner or disconnect it from the production network.
4. Repair the HA link cable, switch port, VLAN or LAG.
5. Restart the device.
6. Check HA status.
7. Check logs and roles.

Additional CLI Commands

In addition to the HA status query under Validate the Cluster, the following read-only command in the Device Console displays interface and link status:

show network interfaces

Expect UP states for the Dedicated HA link and connected Monitored Ports.

In the same output from show network interfaces, locate the affected physical interface by its actual interface name and, alongside the link status, check the available counters for packet drops (Drops), errors and collisions. Not every build displays every counter; missing information does not mean a zero value. Save the output with the node, interface and timestamp, and compare it with a later observation: increasing counters help narrow down interface, cable or negotiation problems, but do not prove a specific cause on their own. Replace cables or correct speed/duplex settings only as a controlled change with administrative access secured and the HA/split-brain precautions described above in place; afterwards, compare counters, link status, roles and synchronisation again. These interface counters must be distinguished from packet drops caused by firewall rules and their Drop Capture.

For link flaps, go to Device Management > Advanced Shell and replace PortE with the actual interface name:

dmesg | grep PortE

The output filters kernel messages for this interface. Repeated link-up/link-down messages indicate cable, transceiver, port or negotiation problems. The command changes nothing, but dmesg contains only the current kernel buffer and does not replace long-term log analysis.

For complete physical troubleshooting with ethtool, module data, and known special cases, see Select and troubleshoot SFP and SFP+ for Sophos Firewall.

Before any deeper intervention, save outputs and timestamps first. The commands were checked against the current Sophos documentation but were not run on the individual customer hardware.

Go-Live Checklist

• Active-Passive or Active-Active selected with a documented reason.
• Models, Flexi Ports, SFOS build, LINCE status, claiming and licences checked.
• Backup and rollback path available.
• Dedicated HA link free, stable and connected as directly as possible.
• VLANs, LAGs, switch ports and RSTP consistent on both sides.
• Peer Admin access to the Auxiliary tested.
• Only stable, critical interfaces selected as Monitored Ports.
• Cluster ID, Initial Primary, Preferred primary and serial numbers documented.
• WebAdmin, CLI status and relevant logs checked.
• LAN, internet, server, VPN, DNAT/WAF, DNS and DHCP tested functionally.
• Failover and switchback tested during a maintenance window.
• Monitoring, firmware, restore and RMA procedures recorded in the runbook.

FAQ