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
HA isn't available on the Wi-Fi models of SG series appliances.
Active-active: Sophos Firewall doesn't support active-active HA for the following:
- DHCP, PPPoE
- Synchronized Application Control (SAC)
For FastPath offloading and acceleration, see Architecture for offloading.
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.
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.
|Traffic||Session failover occurs|
|Forward TCP traffic||Yes|
|Proxy subsystem, both transparent and direct||No|
|IPv4 and IPv6 traffic other than TCP. Example: UDP, ICMP, multicast, broadcast.||No|
|Antivirus scanning sessions||No|
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.
No failover will take place during the backup restoration. This will cause downtime.
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.
- When you're using a VLAN as the HA monitoring link, only the physical parent interface is listed in the monitoring interface's list, and failover is decided based on the physical interface's connectivity. Unless you've manually turned a VLAN interface on or off, its status is always the same as the parent interface's status.
- 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.
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.
Failing back to the primary device
When a failover occurs, traffic is routed through the auxiliary device. Select this option if you want to move back automatically to the primary device when it recovers.
When you set a preferred primary device, the cluster behaves as follows:
- The device you're signed in to when you turn on this option becomes the preferred primary.
- Whenever the preferred primary device restarts or comes up again after a failover, it restarts the peer device once all services are started and synchronized. It then becomes the primary device again.
Here's an example of how this works:
To add a FleXi port module to an existing HA cluster, do as follows:
- Power off both devices.
- Install the same FleXi port module on both devices.
- Power on both devices.
Configure the FleXi port module with an IP address on the primary device.
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.
Save the IP settings configuration.
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.
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.