FortiGate High Availability Active-Passive Configuration and Failover Testing

Deploying a FortiGate HA active passive configuration ensures enterprise networks maintain continuous operations during hardware, cable, or link failures. Fortinet uses the FortiGate Clustering Protocol (FGCP) to manage cluster state, synchronize firewall sessions, and coordinate failover events. In an Active-Passive high availability deployment, one unit actively processes all network traffic while the standby unit continuously synchronizes configuration and session states. If the primary firewall fails, the secondary firewall assumes the active role within milliseconds, preventing service disruptions.

This technical guide details how to plan, build, verify, and test a high-availability active-passive cluster on FortiGate firewalls running FortiOS. You will learn the exact election mechanics, session synchronization principles, CLI and GUI setup procedures, and practical troubleshooting workflows necessary for production readiness.

Real-Life Scenario

An enterprise organization requires zero-downtime architecture for its primary datacenter. The network team is deploying two identical FortiGate appliances to protect critical internal services, web applications, and database infrastructure. The primary business requirements for this cluster include:

• Automatic failover of all perimeter traffic without breaking active TCP sessions.
• Interface monitoring on primary WAN and LAN links to trigger cluster failover if an upstream or downstream link drops.
• Dedicated redundant heartbeat links to prevent split-brain conditions.
• In-band or dedicated out-of-band management access to both firewall nodes individually for maintenance.

Lab Topology

The topology consists of two FortiGate appliances (FGT-A and FGT-B) linked together through dual dedicated heartbeat interfaces. Both units connect to redundant Layer 2 switches on the WAN and LAN sides.

                      +-------------------+
                      |   Upstream WAN    |
                      |   L2/L3 Switch    |
                      +---------+---------+
                                |
               +----------------+----------------+
               |                                 |
        (port1 | 198.51.100.10)           (port1 | 198.51.100.10)
        +------+------+                   +------+------+
        |             |   hb1 (port5)     |             |
        |  FortiGate  +-------------------+  FortiGate  |
        |    FGT-A    |                   |    FGT-B    |
        |  (Primary)  +-------------------+ (Secondary) |
        |             |   hb2 (port6)     |             |
        +------+------+                   +------+------+
        (port2 | 192.0.2.1)               (port2 | 192.0.2.1)
               |                                 |
               +----------------+----------------+
                                |
                      +---------+---------+
                      |    Internal     |
                      |   LAN Switch    |
                      +-------------------+

Example Addressing and Objects

The following table lists the IP addressing, interface assignments, and system roles used throughout this guide. These values represent a lab environment and must be adapted to match your production environment.

Prerequisites

Before configuring FGCP Active-Passive High Availability, verify that both FortiGate appliances meet the following mandatory requirements:

• Identical Hardware Model: Both devices must be the exact same hardware model and revision (for example, two FortiGate-100F units). High availability across different models is not supported.
• Matching Firmware Version: Both units must run the exact same FortiOS release, including major, minor, and patch levels.
• Identical Hardware Storage: Storage configurations must match. If one unit has an internal SSD installed, the secondary unit must have the same drive configuration.
• Licensing Alignment: System licenses (FortiCare, UTM/FortiGuard contracts, Virtual Domain limits) should match. Mismatched subscription services cause feature degradation or synchronization warnings.
• Direct Physical Connections: Connect at least two dedicated physical interfaces directly between the appliances using patch cables for heartbeat redundancy. Do not route heartbeat traffic through unmanaged or shared intermediate switches without dedicated VLAN isolation.

Step-by-Step GUI Configuration

Note: FortiOS GUI menu structures can vary slightly between major releases. The steps below reflect standard FortiOS v7.x navigation.

Step 1: Configure the Primary Firewall (FGT-A)

1. Log into the web-based manager of the primary FortiGate unit.
2. Navigate to System > HA.
3. Set the Mode to Active-Passive.
4. Enter a Device Priority of 200 (higher values increase the likelihood of selection as primary during initial cluster formation).
5. Enter a Group Name (for example, DC-HA-CLUSTER).
6. Set a unique Group ID integer between 1 and 255 (for example, 50). This ID prevents Virtual MAC collisions if multiple FortiGate clusters share the same Layer 2 switch environment.
7. Under Heartbeat Interfaces, click + and select port5 and port6. Assign a heartbeat priority (for example, 50).
8. Under Monitored Interfaces, select your active data interfaces: port1 (WAN) and port2 (LAN).
9. Click Apply.

Step 2: Configure the Secondary Firewall (FGT-B)

1. Log into the web-based manager of the secondary unit before connecting the data cables.
2. Navigate to System > HA.
3. Set the Mode to Active-Passive.
4. Set a lower Device Priority of 100.
5. Specify the exact same Group Name (DC-HA-CLUSTER) and Group ID (50).
6. Select the exact same Heartbeat Interfaces (port5 and port6).
7. Select the exact same Monitored Interfaces (port1 and port2).
8. Click Apply.

Once you apply the settings on the secondary firewall and connect the heartbeat cables, FGT-B connects to FGT-A via FGCP, performs an initial configuration synchronization, and assumes the secondary status.

Executing the FortiGate HA Active Passive Configuration via CLI

The command line provides the precise, deterministic method for establishing an HA cluster. The configuration must be performed on each unit individually before they form the cluster.

Primary Firewall (FGT-A) CLI Setup

config system ha
    set mode a-p
    set group-id 50
    set group-name "DC-HA-CLUSTER"
    set priority 200
    set override disable
    set hbdev "port5" 50 "port6" 50
    set monitor "port1" "port2"
    set ha-mgmt-status enable
    config ha-mgmt-interfaces
        edit 1
            set interface "mgmt1"
            set gateway 203.0.113.1
        next
    end
end

Secondary Firewall (FGT-B) CLI Setup

config system ha
    set mode a-p
    set group-id 50
    set group-name "DC-HA-CLUSTER"
    set priority 100
    set override disable
    set hbdev "port5" 50 "port6" 50
    set monitor "port1" "port2"
    set ha-mgmt-status enable
    config ha-mgmt-interfaces
        edit 1
            set interface "mgmt1"
            set gateway 203.0.113.1
        next
    end
end

Why These Commands Are Required

• set mode a-p: Defines the cluster operation as Active-Passive.
• set group-id 50: Calculates the Virtual MAC (VMAC) offset for cluster interfaces to prevent MAC address duplicates across local Layer 2 broadcast domains.
• set priority: Assigns the node weighting for cluster negotiation. The unit with the highest priority becomes the primary node if all other conditions match.
• set override disable: Disables automatic primary unit failback when a failed unit with a higher priority boots back up. Keeping this disabled prevents unnecessary traffic interruptions caused by secondary failbacks.
• set hbdev: Identifies dedicated physical interfaces for cluster communication, heartbeat checks, and state synchronization.
• set monitor: Enables continuous link-state detection on critical interfaces. If a monitored link goes down, the primary node reduces its internal score to force a failover to the secondary node.
• set ha-mgmt-status enable: Isolates administrative management traffic onto dedicated management interfaces (`mgmt1`), allowing administrators to SSH or connect to the GUI of both physical appliances independently.

How the Traffic Flows

Understanding packet processing within an Active-Passive FGCP cluster clarifies how session persistence and virtual addressing operate behind the scenes.

Virtual MAC (VMAC) Allocation

In an Active-Passive deployment, the primary unit takes ownership of virtual IP addresses on all active data interfaces. To avoid waiting for standard ARP timeouts across connected Layer 2 switches during a failover event, FGCP assigns a Virtual MAC address to each cluster data interface.

The standard FGCP VMAC address format is:

00-09-0f-09-<group-id-hex>-<interface-index-hex>

For example, with a Group ID of 50 (0x32 in hexadecimal), all cluster data interfaces receive a MAC starting with 00-09-0f-09-32-xx. Downstream switches learn this VMAC on the switch port connected to the primary firewall. The secondary firewall keeps its physical data ports active at Layer 1, but drops all inbound and outbound data traffic at Layer 2.

Session Synchronization

When client traffic matches a firewall policy on the primary unit, FortiOS writes the connection state into its local session table. By default, FGCP synchronizes stateful TCP connections across the dedicated heartbeat links (`hbdev`) to the secondary unit.

During normal operations:

1. Client sends TCP SYN to the primary unit.
2. Primary unit processes the packet, creates a session table entry, and transmits a synchronization packet across the heartbeat link to the secondary unit.
3. The secondary unit updates its kernel session mirror.
4. If a hardware failure occurs on the primary, the secondary assumes the primary role, broadcasts a gratuitous ARP containing the VMAC, and immediately processes ongoing TCP connections without requiring clients to re-establish sessions.

Note: UDP, ICMP, and certain non-stateful application sessions are generally not synchronized by default unless explicit session sync settings are applied.

Verification

After completing the configuration and connecting the heartbeat cables, verify cluster operation using diagnostic CLI commands.

Check Cluster Status

Execute the following command on either unit:

get system ha status

Look for the following key indicators in the output:

• Cluster Model: Matches your appliance hardware model.
• Health Status: Displays OK for both heartbeat links.
• Master/Primary Node: Displays the unit with the higher priority (e.g., FGT-A).
• Slave/Secondary Node: Lists the peer unit (e.g., FGT-B) with state marked as in-sync.

Example command output:

HA Health Status: OK
Model: FortiGate-100F
Mode: Active-Passive
Group: 50
Debug: 0
Cluster Uptime: 3 days 04:12:30
Cluster state change time: 2023-10-24 10:15:00
Master selected reason: priority
Primary : FGT-A , FG100FTK21000001, HA cluster index = 0
Secondary : FGT-B , FG100FTK21000002, HA cluster index = 1
System Configuration sync status: in-sync

Verify Checksum Synchronization

To confirm that both appliances share identical configurations, execute:

diagnose sys ha checksum cluster

The command outputs checksum strings for both appliances. If the configuration is fully synchronized, the total global checksum and debug zone checksum values match across all cluster members:

================== Debug State Checksum ==================
is_master: 1
node: 0, serial: FG100FTK21000001, checksum: e4d2a1c09f3b8a1e
node: 1, serial: FG100FTK21000002, checksum: e4d2a1c09f3b8a1e

Failover Testing

Execute a controlled failover test during an approved maintenance window to validate performance:

1. Start a continuous ping from an internal host (192.0.2.100) to an external resource (198.51.100.1).
2. Disconnect the primary WAN cable (port1) on FGT-A.
3. Observe the continuous ping. Failover should complete within 1 to 2 packet drops.
4. Check the HA cluster status on FGT-B using get system ha status. FGT-B should report itself as the primary unit due to port monitoring on FGT-A detecting a link drop.
5. Reconnect port1 on FGT-A. Because override is set to disable, FGT-B remains the primary firewall, preventing an unnecessary second failover.

Troubleshooting

If an active-passive cluster behaves unexpectedly, use the structured troubleshooting workflow below.

1. Configuration Mismatch (OutOfSync State)

Symptom: System HA status displays secondary status as out-of-sync or checksums do not match.

Verification Commands:

diagnose sys ha checksum show

To force the secondary unit to re-synchronize its configuration database from the primary unit, execute this command on the secondary firewall:

execute ha recalculate-checksum

2. Split-Brain Condition

Symptom: Both FortiGate units claim to be the primary master simultaneously, causing massive packet loss and IP collisions.

Likely Cause: Loss of all heartbeat connectivity between units (e.g., disconnected cables, misconfigured VLANs, or dead ports).

Verification: Check physical interface states on port5 and port6. Ensure heartbeat interfaces are plugged in directly and not passing through an unconfigured intermediate switch.

3. Real-Time Debugging

CAUTION: Running real-time debug commands on high-volume production firewalls can increase CPU utilization. Run debugs only when necessary and ensure you stop the process when finished.

To inspect heartbeat communication and HA state daemon messages in real time, run:

diagnose debug application hatalk -1
diagnose debug enable

After collecting diagnostic output, safely disable debug logging by executing:

diagnose debug disable
diagnose debug reset

Common Mistakes

• Forgetting to Set a Unique Group ID: If two separate HA pairs exist on the same Layer 2 switch topology using the default Group ID of 0, both clusters generate identical Virtual MAC addresses, leading to severe network flapping.
• Enabling Auto-Override Unintentionally: Setting set override enable causes the cluster to fail back to a higher-priority device the moment it reboots. If that device has an underlying hardware fault, the network will loop through continuous failover states (flapping).
• Monitoring Heartbeat Interfaces: Do not add heartbeat links (`port5`, `port6`) into the set monitor list. Only data plane interfaces (WAN, LAN, DMZ) should be monitored.
• Using Unreliable Intermediate Switches for Heartbeats: Running heartbeat traffic through unmanaged third-party switches introduces single points of failure and packet delays that can cause unnecessary failovers.
• Mismatched Hardware or Modules: Attempting to build an HA pair using nodes with different RAM configurations, transceivers, or disk layouts will result in cluster failure or unsynchronized states.

Production Considerations

When preparing an Active-Passive FortiGate cluster for production environments, review the following operational best practices:

1. Rolling Firmware Upgrades

FGCP supports zero-downtime firmware upgrades. When an upgrade is initiated from the primary unit, FortiOS automatically uploads the firmware image to the secondary unit first. The secondary unit updates, reboots, and assumes the primary role. The former primary unit then updates, reboots, and rejoins the cluster as the new secondary unit.

2. Session Synchronization Tuning

While session sync is vital for stateful connections, high-volume transactional traffic (such as rapid short-lived DNS or HTTP queries) can exhaust heartbeat bandwidth. Consider tuning performance or excluding non-critical connection types if heartbeat links experience high utilization.

3. Dedicated Out-of-Band Management

Always configure ha-mgmt-interfaces. Reserving dedicated management ports (e.g., mgmt1) with distinct IP addresses allows your monitoring systems (SNMP, Syslog, FortiAnalyzer) to poll each firewall node independently, regardless of which unit is currently active.

Related FortiGate Guides

• FortiGate SD-WAN configuration
• FortiGate session troubleshooting
• FortiGate packet sniffer and debug flow
• FortiGate LDAP with Active Directory

Summary

A proper FortiGate HA active passive configuration provides high-availability network protection for mission-critical enterprise environments. By configuring dedicated heartbeat interfaces, enforcing explicit group IDs, setting up monitored data interfaces, and adhering to strict firmware matching, network administrators can deploy a resilient cluster capable of handling hardware and link outages seamlessly.