FortiGate High Availability and Failover

High availability, or HA, is a way to make a network service — in this case, a firewall — always available even when one physical device fails. Think of it as a safety net. Without HA, if your only firewall crashes, every computer, phone and server behind it loses internet access, internal communication and security protection. A single point of failure like that is unacceptable for any business that cannot afford downtime.

A FortiGate HA cluster is a group of two or more FortiGate firewalls that operate as a single logical unit. The cluster has a primary unit (sometimes called the active or master unit) and one or more backup units (often called passive or subordinate units). The primary unit handles all live traffic — it inspects packets, enforces security policies, performs NAT and logs activity. The backup unit sits ready, doing nothing with live traffic, but constantly receiving a copy of the primary's configuration and connection information so it can take over instantly if needed.

The heartbeat link is the dedicated connection between the cluster members. It is a physical cable (often an Ethernet cable) connecting two designated HA interfaces on each FortiGate. Over this link, the units exchange keepalive messages every few hundred milliseconds to confirm the other unit is still alive. If the primary stops sending these heartbeats, the backup assumes the primary has failed and begins acting as the new primary. The heartbeat link also carries configuration synchronisation data, so both units always have the same settings.

Session synchronisation is the process by which the primary shares the state of every active connection with the backup. For example, if a user is streaming a video and the firewall has already inspected and allowed that TCP connection, the backup learns about that session. If the primary fails mid-stream, the backup already knows about that connection and continues forwarding the video packets without asking the user to reconnect. Without session synchronisation, every existing connection would drop, and users would have to re-establish them, causing noticeable interruption.

Failover is the event when the backup takes over because the primary has failed. Failover is triggered by specific conditions, such as:

During failover, the backup unit assumes the shared virtual IP addresses — the IP addresses that hosts on the network use as their default gateway. Because those IPs move from the primary to the backup, client devices do not need to change any settings. They keep sending traffic to the same gateway IP, and the backup now responds.

There are two main HA modes on FortiGate: active-passive (A-P) and active-active (A-A). In active-passive mode, one unit handles all traffic while the other sits idle. This mode is simpler and recommended for most deployments because it avoids complexity around asymmetric routing. In active-active mode, both units handle traffic simultaneously. This increases throughput but requires careful design to prevent traffic from arriving at one firewall and leaving through the other, which can break stateful inspection.

The cluster uses a priority system to decide which unit becomes primary. Each FortiGate has a configurable priority value (higher number = more likely to be primary). If priorities are equal, the unit with the lower serial number wins. Once a primary is elected, it remains primary unless it fails or the administrator initiates a manual failover.

Configuration synchronisation ensures that you only make changes on the primary unit. The primary then pushes those changes to all backup units automatically. This includes firewall policies, VPN settings, routing tables, DHCP server configs and NAT rules. You do not need to log into each firewall separately. This consistency is critical: if one unit had different rules, traffic might behave differently after a failover.

Troubleshooting HA involves checking the HA status dashboard, verifying heartbeat link connectivity, reviewing logs for failover events and confirming that session synchronisation is working. Common problems include mismatched firmware versions, incorrect HA interface configuration, blocked heartbeat traffic or incompatible HA modes between units.

For NSE7, you need to know that HA clusters require identical hardware models, the same FortiOS version and consistent licensing. Mixing models or firmware versions will prevent cluster formation or cause unpredictable behaviour.

An IT professional manages network security for a company with 500 employees spread across a headquarters and two remote offices. One day, the primary FortiGate at headquarters starts emitting a warning beep — the power supply is failing. The IT team needs to replace it without taking the whole company offline.

Because the team configured an active-passive HA cluster months ago, two FortiGates sit in the rack connected by a short heartbeat cable. Both run identical firmware and share the same configuration. The backup FortiGate has been silently synchronising sessions and configuration from the primary.

At 2:00 PM, the IT engineer opens the FortiGate GUI, navigates to the HA dashboard and confirms the cluster status shows both units as 'members' with the primary handling traffic. They verify that session synchronisation counters are increasing, which confirms live sessions are being copied to the backup. They also check that the monitored ports — WAN1, LAN1 and DMZ — all show green status on both units.

To prepare for the hardware replacement, the engineer performs a controlled failover. They go to the HA settings, find the 'Override' option and set it on the backup unit temporarily, forcing it to become primary. Within a second, all traffic shifts to the backup. The engineer checks that remote office VPN tunnels have re-established and that employees can browse the web, access internal servers and send email. Everything works.

Now the original primary is safely powered down and removed. The engineer installs the replacement FortiGate, connects the heartbeat cable and power, and watches the HA dashboard. The new unit appears as a 'backup' member after configuration synchronisation completes. The engineer then removes the override so the original priority settings apply. If the new unit has a higher priority, it will become primary again; if not, the current primary stays.

The team documents the exact serial numbers, firmware versions and HA configuration parameters for future troubleshooting. They also set up SNMP alerts so the network monitoring system sends a notification if a failover occurs unexpectedly at 3 AM.

In a real-world break-fix scenario, without HA, the IT team would need to:

With HA, there is no downtime, no announcements and no loss of active connections. The business continues operating as if nothing happened. The IT professional's actual job in this scenario is proactive planning: choosing HA mode, sizing the heartbeat link correctly, setting up monitored interfaces and testing failover regularly.