HA operation

Feature support

The list below details the feature support when using HA.

  • DHCP, PPPoE: When interfaces are dynamically configured using DHCP or PPPoE, HA is supported only in active-passive mode. HA in active-active mode isn't supported.
  • Cellular WAN configuration isn't supported in any HA mode.
  • Synchronized Application Control (SAC) isn't supported in active-active mode.
  • HA isn't available in all Wi-Fi models of XG Firewall.
  • Additionally, HA isn't available in the following models from other firewall series: CR15i, CR15wi, CR25wi, CR35wi, CR15wiNG, CR25wiNG/6P, CR25wiNG/6P, and all Wi-Fi models of the SG series.

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's administrative services (HTTP, HTTPS, Telnet, SSH) are allowed, while the DMZ zone only allows HTTPS and SSH services.
  • When you turn on HA, a virtual MAC address is created for the HA pair.
  • For AV scanned sessions, 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 IPv6 forwarded traffic like ICMPv6, UDP, multicast, and broadcast traffic, session failover isn't possible.


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.

HA load-balancing

The list below details how traffic is load-balanced when using HA.

  • 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.
Note 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.
  • 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.
  • The heartbeat keep-alive, which is the interval between heartbeat packet exchange by HA peers to confirm that the cluster is functioning, is 250 milliseconds.
  • 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.


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.

Session failover in HA in active-passive

The table below shows what kind of traffic is supported by session failover in active-passive mode.


Session failover supported

Forward TCP traffic


Proxy subsystem, both transparent and direct


VPN traffic


IPv4 and IPv6 traffic other than TCP. Example: UDP, ICMP, multicast, broadcast.


System-generated traffic


Antivirus scanning sessions