HA operation

Feature support

Active-passive and Active-active: Sophos Firewall doesn't support active-passive and active-active HA for the following:

• Cellular WAN configuration
• Wi-Fi models

Active-active: Sophos Firewall doesn't support active-active HA for the following:

• DHCP, PPPoE
• Synchronized Application Control (SAC)

Network traffic

Here's how network traffic behaves in HA mode.

• Masqueraded connections: If you manually synchronize any of the HA cluster devices, the firewall drops all the masqueraded connections.
• When you disable HA, the LAN zone allows all administrative services (HTTP, HTTPS, SSH), while the DMZ zone only allows HTTPS and SSH services. This applies only to the auxiliary device. The primary device continues to function as normal in standalone mode.
• When you enable HA, a virtual MAC address (VMAC) is created for the HA pair. This causes a short network outage.
• For AV scanned sessions, every session or file currently being scanned needs to be rescanned, as session failover isn't possible.
• Session failover doesn't occur for IPv4 forwarded traffic, such as ICMP, UDP, multicast, and broadcast traffic, traffic passing through proxy subsystem (transparent, direct, and parent proxy traffic), and VPN traffic. For example, a VPN connection disconnects briefly before automatically reconnecting to the new primary device.
• Session failover doesn't occur for IPv6 forwarded traffic, such as ICMPv6, UDP, multicast, and broadcast traffic.

Email

Here's the email behavior in HA mode.

• In active-active mode, email is quarantined separately on both devices. SMTP proxy traffic is load-balanced in a round-robin manner.
• In active-passive mode, email is quarantined only on the primary device.
• If you've configured quarantine digest, both devices in the cluster will send the quarantine digest email.
• Administrators can release the quarantined email of any users from both devices.
• Users can release quarantined emails from the user portal. The user portal only displays email quarantined on the primary device. Users can also release quarantined mail from the quarantine digest sent from the primary device.

Session failover in HA active-passive mode

The following table shows the traffic for which session failover occurs and doesn't occur in active-passive mode.

HA load-balancing

Here's how traffic is load-balanced when using HA in active-active mode.

• An active-active HA cluster does not load-balance VPN sessions, UDP, ICMP, multicast and broadcast sessions, scanned FTP traffic, and traffic coming through wireless RED devices and access points. TCP traffic for the user portal, web admin console or telnet console, and H.323 traffic sessions are also not load-balanced between the cluster devices. Control traffic for all modules isn't load-balanced.
• An active-active HA cluster will load-balance normal forwarded TCP traffic, including NAT (both SNAT & virtual host) forwarded TCP traffic. This includes TCP traffic passing through a proxy subsystem, such as transparent proxy, direct proxy, parent proxy, and VLAN traffic.
• HTTPS connection load-balancing is supported.

Backup and restore

Here's the behavior when you restore a backup to a device running in HA mode.

• If you restore a backup without HA configuration after you configure HA, HA is disabled, and the primary device is accessible according to the backup configuration. You can access the auxiliary device using the auxiliary admin IP address.
• If you restore a backup with HA configuration to a new device or a factory-reset device, HA is disabled for that device. You must configure HA again.
• If you restore a backup with HA configuration on the primary device, the operation restores the configuration and then restarts the primary device. It then restores the configuration to the auxiliary device and then restarts it. HA is restored automatically, and no additional configuration is required.

Management

The list below provides management information for devices in HA.

• You can disable HA from either device. If you disabled it from the primary device, HA will be disabled on both devices. If you disabled it from the auxiliary device, HA won't be disabled on the primary device and, it'll act as a standalone device.
• When you disable HA, the primary device IP schema won't change. If you have disabled the VMAC, the IP schema will update and another network outage will occur.
• When you disable HA, all the ports except the dedicated HA link port and peer administration port will be disabled for the auxiliary device. The peer HA link IP will be assigned the IP address assigned to the dedicated HA link port, while the peer administration port will be assigned the IP address assigned to the peer administration port.
• When you disable HA from a standalone device, the IP schema won't change.
• Administrator privileges are required to access the auxiliary device admin console and can only be accessed by administrator users. The live users, DHCP leases, and IPsec live connections pages won't be displayed.
• For the auxiliary device, the deployment assistant won't be accessible.
• HA is disabled if you run the deployment assistant.
• HA is supported on the bridge interface when you configure the bridge from the GUI. However, if you run the assistant with bridge mode after configuring HA, HA will be disabled.
• The link uptime, which is the time taken by the dedicated link or monitored port to come up, is three seconds.
• HA won't work correctly when a shared port is used as the dedicated HA link.
• When you connect to the primary or the auxiliary device for administration, the client from which the HA setup is being accessed must be directly reachable. For example, if you're accessing the auxiliary device, then the client's IP and the auxiliary device's IP must be in the same subnet. You can't access the auxiliary appliance via the primary. If you try to route the packet through the primary, the auxiliary receives it with an IP already set in one of its interfaces (because it's a replica of the primary), and the request isn't served.

Reports

Here's the reporting behavior in HA mode.

• Each device in the HA pair has its own report data based on the traffic it processes. On-box reports generated on one device in the HA pair don't include report data from the other.
• Reports generated via Sophos Central combine reports from an HA pair.

Failover

Here's the behavior when a failover occurs.

• If a device doesn't receive any communication from the HA peer within the predetermined time, the peer device is considered to have failed. This process is termed device failover, as when this occurs, the active device takes over the peer device.
• The device failover detection time (peer timeout) is four seconds. When the primary device stops sending heartbeat packets, it's declared inactive at the end of four seconds (250 milliseconds x 16 timeouts). The peer is considered active if a heartbeat is received within fourteen timeouts. Failover is triggered at the end of seven seconds (three-second link uptime + four-second device failover detection time) from the time cluster has come up. You can't change the failover threshold.

Expansion modules

To add a FleXi port module to an existing HA cluster, do as follows:

1. Power off both devices.
2. Install the same FleXi port module on both devices.
3. Power on both devices.

4. Configure the FleXi port module with an IP address on the primary device.

   Note

   The firewall synchronizes the IP address you configure on the FleXi port module to the auxiliary device, but the traffic doesn't flow through this interface IP until you save the IP settings configuration again.

5. Save the IP settings configuration.

Licensing

Active-passive HA

You must activate the licenses on the device you've configured as the initial primary. The licenses are synchronized with the secondary device.

The initial primary device can be the active or the passive device. The behavior is as follows:

• Initial primary as the passive device: As long as the initial primary device works as the active or passive device, it synchronizes the licenses with the licensing server, and the HA cluster continues to protect the network.

• Initial primary isn't working: If the initial primary device isn't working and can't synchronize with the licensing server at least once in 90 days, license protection is deactivated.

  For hardware appliances, only the Base Firewall and Enhanced Support license remain active.

  For virtual and software appliances, the Base Firewall license is also deactivated.

Active-active HA

Both devices carry licenses independently. When either of the devices is working and synchronizes with the licensing server, the HA cluster continues to protect the network.