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

The list below details network traffic behavior when using HA.

• Masqueraded connections: If you manually synchronize any of the HA cluster devices, the firewall drops all the masqueraded connections.
• When you disable HA, all the LAN zone allows administrative services (HTTP, HTTPS, SSH), while the DMZ zone only allows HTTPS and SSH services. This applies to the auxiliary device only, the primary device will continue to function as normal in standalone mode.
• When you turn on 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.
• For IPv4 forwarded traffic, like ICMP, UDP, multicast and broadcast traffic, traffic passing through proxy subsystem (transparent, direct, and parent proxy traffic), and VPN traffic, session failover isn't possible. For example, a VPN connection will disconnect briefly before it automatically reconnects to the new primary device.
• For IPv6 forwarded traffic like ICMPv6, UDP, multicast, and broadcast traffic, session failover isn't possible.

Email

The list below details email behavior when using HA.

• In active-active mode, email is quarantined separately on both the devices. SMTP proxy traffic is load-balanced in a round-robin manner.
• In active-passive mode, email is only quarantined on the primary device.
• If you have 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 email 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 table below shows what kind of traffic is supported by session failover in active-passive mode.

HA load-balancing

The list below details how traffic is load-balanced when using HA 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

The list below details the behavior when you restore a backup to a device running in HA.

• If a backup without HA configuration is restored (after configuring HA), HA is disabled, and the primary device will be accessible according to the backup configuration, while the auxiliary device will be accessible with the auxiliary admin IP address.
• If a backup with HA configuration is restored to a new device or a factory-reset device, HA is disabled for that device. You need to repeat the HA configuration process.
• If a backup with HA configuration is restored on the primary device, it'll restore the configuration and then restart the primary device. It'll then restore the configuration to the auxiliary device and then restart the auxiliary device. HA will be 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.

Failover

The list below details 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

When you add a FleXi port module to an existing HA cluster, the steps are 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 in the primary appliance. The recently added new IP on the FleXi port module is synced to the secondary unit, but traffic can't flow through this interface IP until the IP settings configuration is saved again.