Fortinet NSE4_FGT_AD-7.6: FortiGate HA Failover Design
FortiGate high availability should be designed as a failure system, not as a checkbox that turns two appliances into one. The Fortinet Cluster Protocol synchronizes cluster state and elects a primary member, but the quality of the design depends on heartbeat links, monitored interfaces, session synchronization, device priorities, network topology, management access, upgrade behavior, and what the surrounding switches, routers, and providers do when ownership changes.
Fortinet’s current FortiOS 7.6 documentation distinguishes active-passive and active-active FGCP clusters and describes election behavior using device priority, override configuration, uptime, monitored interfaces, and serial number as relevant factors. It also documents session-pickup and related synchronization options for preserving traffic where the protocol and session type allow it. These controls are useful only when the network around the cluster is designed to converge with them.
HA design therefore belongs inside Network Security Platforms.
Design the failure domains first
Identify which failures the cluster should survive: appliance loss, interface failure, switch failure, power loss, software failure, maintenance, or site failure.
High availability is a system property because two FortiGates connected to one switch and one power source do not protect against those shared dependencies.
The HA pair should sit inside a topology whose upstream and downstream paths can also survive the failure modes the business cares about.
Protect heartbeat connectivity
FGCP members use heartbeat interfaces to exchange cluster state, election information, and synchronization traffic.
Use dedicated or carefully planned heartbeat links, avoid accidental loops, and ensure heartbeat capacity is sufficient for synchronization requirements.
A heartbeat design that can fail together with the production path can create split-brain or unnecessary failover behavior rather than resilience.
Monitor interfaces that matter
Interface monitoring lets the cluster react when a critical data path fails even though the appliance itself remains alive.
Do not monitor every interface automatically. Monitor the links whose failure should move traffic to the peer.
FortiGate HA behavior becomes predictable when the team can explain which failure changes member health and which does not.
Understand the election model
Cluster election depends on current conditions and configuration rather than one permanent “master” label.
Device priority and override can influence which member becomes primary, but uptime and failure history can also affect behavior according to the current HA state.
The design should decide whether deterministic primary preference is important enough to use override or whether avoiding unnecessary failback is more valuable.
Plan session pickup by traffic type
Session pickup can synchronize supported session information so traffic has a better chance of surviving member failover.
Not every session type or inspection state can resume identically, and some protocols tolerate reconnect better than others.
Session state should be part of HA testing so teams know whether critical TCP, UDP, VPN, and inspected flows recover transparently or reconnect.
Keep L2 and routing behavior aligned
When the primary changes, adjacent switches and routers need to direct traffic toward the new active path.
Gratuitous ARP, dynamic routing adjacencies, static routes, link aggregation, SD-WAN, and upstream provider behavior can all influence convergence.
Routing diagnostics should be included in failover validation rather than assuming the HA election alone proves the packet path recovered.
Design management access for failures
Operations teams need a way to reach the cluster and, when necessary, individual members during an outage.
Use reserved management interfaces, out-of-band networks, or documented per-member access where the topology supports it.
A cluster that keeps forwarding traffic but cannot be diagnosed safely during a failure is harder to operate than the design diagram suggests.
Test upgrades and maintenance
HA should reduce maintenance risk, but firmware upgrades, configuration synchronization, and planned member failover still need change control.
Validate the upgrade path in the context of supported upgrade sequences and the actual inspection, VPN, routing, and session features in use.
FortiGate troubleshooting should have a known rollback and diagnostic sequence before the first production maintenance window.
Measure recovery, not only election
An HA test is complete when the business flow recovered, not when the secondary became primary.
Measure packet loss, session impact, route convergence, VPN recovery, application reconnect time, logging continuity, and management access.
For FortiGate administration, the durable design is failure domain → heartbeat → monitored path → election → synchronized state → network convergence → measured application recovery.
HA testing should include partial failure. Disconnect one monitored uplink, degrade a switch path, remove a routing neighbor, and break a heartbeat link separately. Different failures can create very different outcomes, and a cluster that survives complete power loss may still behave poorly when only one transit path disappears.
Asymmetric traffic deserves attention in stateful inspection. If upstream routing sends one direction through a different member or firewall path, sessions can fail even while both appliances are healthy. Keep routing and switching designs symmetric enough for stateful policy or explicitly use designs that account for asymmetry.
Capacity planning should assume one member can carry the required load after failover. A pair running near combined capacity can become overloaded the moment one device disappears. Include SSL inspection, IPS, VPN, logging, and session count in the failover capacity test rather than using only raw firewall throughput.
Finally, document the intended primary preference, monitored interfaces, heartbeat links, session-pickup policy, management path, and failover acceptance criteria. The cluster should be understandable to the operator who receives the incident at 3 a.m., not only to the engineer who built it.
Cluster membership should be documented by serial number, role expectation, firmware, interface mapping, and physical location. In real outages, operators need to know which appliance they are looking at and whether a cabling problem affects the expected primary or peer. Label heartbeat and data links consistently on both the device and switch side so a maintenance task cannot accidentally remove both redundancy paths.
Switch design is a common hidden dependency. If both FortiGates connect through the same access switch or the same line card, the HA pair may survive an appliance failure but not a switching failure. Where availability requirements justify it, distribute links across independent switches or stacks and validate LACP, spanning-tree, and gateway behavior through failover.
Dynamic routing can create a recovery time longer than the FGCP role change itself. BGP or OSPF neighbors may need to re-form, routes may be withdrawn and reinstalled, and upstream devices may keep stale paths briefly. Capture routing convergence during HA testing so the business understands whether application recovery is sub-second, several seconds, or longer.
VPN state deserves protocol-specific testing. IPsec tunnels, SSL VPN sessions, and remote-access clients do not necessarily behave like ordinary transit TCP sessions. A user may reconnect automatically while a site-to-site tunnel renegotiates or a session loses state. Record the expected recovery for critical VPN-dependent applications instead of assuming “HA” means no visible interruption.
Configuration synchronization should also be monitored. Most cluster configuration is synchronized, but member-specific settings, management interfaces, and hardware-dependent options can differ. After a major configuration change, confirm cluster sync status before treating the peer as a known-good standby. A failover into a member that has not synchronized is worse than a clean outage because the symptoms can be inconsistent.
Split-brain planning matters in stretched or unusual topologies. If heartbeat communication fails while both members retain production connectivity, duplicate active behavior can create MAC, ARP, routing, or state problems. Fortinet provides HA mechanisms to prevent and detect unhealthy cluster conditions, but architecture should minimize the chance that heartbeat isolation happens independently from data-plane reachability.
HA monitoring should include more than device up/down. Track member role, cluster checksum or sync health, monitored-interface state, heartbeat errors, session synchronization, routing neighbor state, and recent failover events. An “all green” dashboard is meaningful only if it can reveal a degraded cluster that has silently lost redundancy before the next fault occurs.
Planned failover is a useful operational exercise. Periodically move primary responsibility under controlled conditions and verify application traffic, logging, VPNs, dynamic routing, and management access. This both validates redundancy and keeps the operations team familiar with what normal failover looks like, reducing uncertainty during a real incident.
Failure testing should also include recovery of the failed member. Confirm how it rejoins, synchronizes, and resumes the intended role. If override is enabled, understand whether the returning preferred member causes another role change. Unnecessary failback can create a second interruption immediately after the first incident was resolved.
The strongest HA design therefore treats FGCP as one layer in a chain of resilience. Power, switches, routes, WAN providers, VPN peers, management, logging, and application retry all participate in the result the user sees. Two firewalls are useful, but the service is highly available only when the entire path has been designed and tested around failure.
HA documentation should also record which states are expected to synchronize and which are not. Session pickup, IPsec information, configuration, and routing behavior can each have feature-specific limitations. Critical applications should be tested against the exact protocol and inspection mode they use rather than relying on a generic claim that “sessions survive failover.”
Keep one baseline failover report with measured results. Record packet loss, route convergence, VPN impact, management reachability, log continuity, and application recovery. Future firmware or topology changes can then be compared against a known healthy baseline instead of evaluated from memory.