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, both devices, firmware builds, licences, cabling and management access must match.

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

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.

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 fully synchronised between the 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.
• During failover, the Auxiliary Firewall takes over with the same virtual MAC address.
• 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 as one factor for distribution: TCP connections from even-numbered source IP addresses are typically processed by the Primary, while odd-numbered addresses can go to the Auxiliary. Forwarded or translated TCP connections are distributed. Non-TCP, SD-RED and tunnelled traffic, as well as Layer 7 connections through DPI or a proxy—including SMTP Proxy, HTTPS, scanned FTP and H.323—are not distributed. Sophos does not support external load balancers in front of the cluster for this HA logic.

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.
• Preferred primary: Preferred device that should become Primary again after failover once it is stably available.

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

Sophos Firewall uses virtual MAC addresses for production interfaces in an HA cluster. Only the Primary answers ARP requests for the cluster. During failover, the Auxiliary takes over this virtual MAC address. This helps maintain reachability for switches, routers and clients because the IP-to-MAC mapping does not fundamentally change.

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.
• Secure Storage Master Key and WebAdmin credentials are synchronised.
• The Dedicated HA link is not synchronised as a normal production interface configuration.
• The Peer Admin Port is handled separately and is not synchronised like a normal interface.
• Logs and reports are not synchronised between the devices.

Failover Behaviour

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 shows the read-only diagnostic command and explains why both Nodes must not be restarted without coordination or HA disabled based only on suspicion.

Heartbeats run over the dedicated HA link. Very short intervals are used by default. If several consecutive heartbeats are missed, the peer is considered unreachable. The firewall then evaluates the state and performs the role change.

Many connections continue or are re-established quickly during failover. However, failover is not fully transparent for every application. Stateful TCP connections, web sessions, proxy connections and certain VPN scenarios in particular may briefly disconnect or need to reconnect.

Supported and Restricted Services

Sophos HA supports most firewall services, but some services have special characteristics.

• Firewall rules and NAT are synchronised. In Active-Active, it is important to know which node processes a connection.
• VPN works in many HA scenarios, but not every session type fails over without interruption. IPsec can take over stateless UDP/ICMP traffic more effectively than stateful TCP.
• Web Protection works in the cluster. In Active-Active, alerts can originate from both nodes.
• Email Protection quarantine and release operations can be node-specific because each device stores its own data for processed email traffic.
• Synchronized Application Control is unsuitable for Active-Active when the function is not supported in the SFOS version in use.
• NDR Essentials should be planned only with Active-Passive in HA environments.
• sFlow runs only on the Primary in HA environments.
• Reports are generated locally on each device. Sophos Central Firewall Reporting is more suitable for consolidated reports.
• Cellular WAN must be disabled for HA.
• XGS Wi-Fi models do not support HA.

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.

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 model, for example XGS 2100 with XGS 2100.
• Hardware revision: Different hardware revisions are possible with the same XGS model.
• XGS 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 of Flexi Ports.
• Firmware: Both devices must run the same SFOS version, including Maintenance Release and build.
• Hardware plus virtual appliance: Cannot form an HA pair.

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.

• Platform: Same appliance type and SFOS platform.
• Hypervisor: Same hypervisor type.
• Resources: Same CPU core count, comparable resources 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.

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.

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 this licence by default. Virtual/Software appliances must be licensed accordingly.
• 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 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: Support status is important for hardware replacement and Advance Replacement. For Active-Passive hardware, Sophos identifies Enhanced Plus Support on the Primary as a relevant prerequisite for Advance Hardware Replacement. In Active-Active, the support status must be appropriate on both devices.

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.

If Active-Active licences differ, load balancing stops for up to three days. If the mismatch continues, the firewall disables HA. Active-Active is not activated during initial setup when licences do not match.

The Initial Primary must synchronise the licences 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.

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 synchronised
• 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 or PPPoE, but these connections do not have session failover.

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. 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. The administration ports of both devices must be in the same subnet but use different IP addresses. QuickHA automatically uses the interface through which the current WebAdmin session is connected. After HA is established, the Auxiliary is reachable only through the Peer Admin address from a suitable network.

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.

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.
• 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:

• Admin ports in the same subnet but with different IP addresses: Otherwise, HA cannot be established correctly or the Auxiliary will not be reachable later.
• 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.

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. After a device replacement, HA must therefore be disabled and configured again.

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.

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. Optionally assign a 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. Optionally assign a node name, 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 Central registration, if used

4. Set Monitored Ports

Monitored Ports determine whether an interface failure triggers failover. Typical candidates are:

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

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?
• 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.

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.
5. Select the critical Monitored ports.
6. Under Peer administration settings, specify the management interface and a dedicated IP address for FW02.
7. For virtual appliances, select the MAC address assigned by the host or hypervisor if required. Changing it later causes downtime.
8. Set the Preferred primary and select Initiate HA.

After setup, change the keepalive values only for a documented reason. By default, the firewall sends a heartbeat every 250 milliseconds and considers the peer unreachable after 16 missed heartbeats.

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

Primarily check which device is the licence-holding Initial Primary under System services > High availability. In a documented support case, the following internal read-only value in the Advanced Shell can provide additional information:

nvram get "#li.master"

YES usually identifies the Initial Primary and NO the Auxiliary. Sophos does not document this internal Advanced Shell command as a regular administrative interface, so the HA view remains the reference.

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 Central, 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.

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.

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 can react briefly.

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

Backup and restore have special characteristics in HA environments:

• Create backups regularly and before every major change.
• Restore to the current Primary Firewall.
• After a restore, both firewalls are deregistered from Sophos Central and must be registered again.
• A restore causes a restart and downtime, not a normal failover.
• Restoring a backup without HA configuration to an HA cluster disables HA, which must then be rebuilt.
• If LINCE is enabled, the backup and target cluster must have the same LINCE status.

If the cluster uses Sophos Central 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.

1. Check that the replacement model and hardware revision are suitable and install exactly the same firmware build as on the healthy Primary.
2. Claim the replacement device in Sophos Central 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 Central.
2. Bring the replacement device to the same firmware build, claim it in Sophos Central 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, claim it again in Sophos Central 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: Monitor & Analyze > Logs > Troubleshooting logs 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 models.
• HA could not be enabled: The Dedicated HA link may not be connected or the peer may be unreachable. Check port status, cable, switch and ping to the HA link IP, then stabilise the cabling or HA link.
• 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: Admin Ports or HA link addresses are not in the expected subnet. Check the IP addresses and /log/syslog.log, then correct the addressing.
• 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 does not work: Speed/duplex or auto-negotiation may not match. Check Interface Advanced settings on both devices and configure both sides identically or use a fixed port.

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

show network interfaces

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

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

Official sources: Registration and licences · LINCE in HA environments · RMA in an Active-Passive cluster · HA FAQ