Set Up Active-Passive HA Between Two FortiGate Firewalls

Before you run this

This guide builds an FGCP active-passive cluster from two FortiGate firewalls: one unit passes all traffic while the second stays fully configured and idle, ready to take over within seconds if the primary fails. The two units share one configuration, one set of virtual MAC addresses, and appear on the network as a single firewall.

You need super-admin (prod-profile) access to both units — HA settings live under config system ha and the GUI System > HA page, both of which require full administrative rights.

Read this through before you touch anything, and if you can, build it once on a pair of VMs (FortiGate-VM images) or a bench pair before you do it on the firewall carrying production traffic. HA forms a cluster by overwriting the secondary unit's entire configuration with the primary's — that is the whole point, but it means the secondary's existing config is gone. Treat that as irreversible.

This is a live-firewall change, so:

• Keep a console connection open to the unit you are configuring (serial console cable, or the dedicated MGMT port on a separate cable). A heartbeat or interface mistake can drop your SSH/GUI session and cut production traffic at the same time. The console does not depend on the data-plane config.
• Back up the running config of both units first. GUI: the config/backup control on the dashboard (System > Configuration > Backup area in FortiOS 7.4), or CLI execute backup config to your preferred destination. Keep both files off-box.
• Do it in a maintenance window. Cluster formation causes a brief reboot/renegotiation, and the shift to virtual MACs makes directly connected switches re-learn the firewall's MAC — expect a short traffic blip.
• Rollback path: if the cluster misbehaves, disconnect the heartbeat links, set config system ha back to set mode standalone on each unit, and restore the pre-change config backup you took above. There is no timed auto-rollback on FortiOS HA — your backup file is your undo.

What I'm assuming

• Two identical FortiGate units: same model, same FortiOS build (7.4.x). FGCP will not form a stable cluster across mismatched models or firmware — match them exactly first.
• Both units are licensed/registered and reachable.
• You have two spare interfaces per unit to dedicate to the heartbeat (I use port3 and port4 below). Never carry heartbeat on an interface you also use for production traffic.
• You will use direct-attached copper between the two units for heartbeat — the standard, simplest topology. Heartbeat over a switch is possible but I am not covering it here.
• Interface names (port1, mgmt, etc.) vary by model. Substitute the names your hardware actually shows in show system interface.

Physical setup first

1. Cable the two dedicated heartbeat interfaces directly: primary port3 → secondary port3, and primary port4 → secondary port4. Two links so the heartbeat itself is redundant.
2. Cable the data interfaces (WAN, LAN) on both units into the same upstream switch/network. Once clustered, only the primary's ports are active, but the secondary must be able to take over the same links.
3. Confirm both units boot to the same firmware version before going further.

Configure the primary unit

Configure the unit you want to be primary first. Replace the placeholders — MyClusterName, the password, the interface names — with your own.

config system ha
    set group-name "MyClusterName"        # any name; must match on both units
    set mode a-p                          # active-passive
    set password <a-strong-shared-secret> # must match on both units
    set hbdev "port3" 100 "port4" 100     # heartbeat interfaces + priority
    set session-pickup enable             # secondary keeps existing sessions on failover
    set override disable                   # avoid failover flapping (see below)
    set priority 200                      # higher = preferred primary
    set monitor "port1" "port2"           # interfaces whose link-down triggers failover
end

A few notes on those lines:

• set password and set group-name must be identical on both units, or they will not pair.
• set monitor lists the production interfaces to watch. If a monitored interface loses link on the primary, the cluster fails over. List only the interfaces that genuinely matter — monitoring everything makes the cluster twitchy.
• set override disable is deliberate. With override off, whichever unit is currently primary stays primary until it fails, which avoids a preferred unit repeatedly grabbing control and causing repeated blips. If you specifically want a fixed unit to always reclaim the primary role, enable override — but understand it causes an extra failover when that unit recovers. I leave it disabled for most sites.
• There is also an HA group ID setting that determines the cluster's virtual MAC addresses. If you run more than one FortiGate cluster in the same L2 domain, each cluster needs a distinct group ID to avoid MAC conflicts. Check the FortiGate HA chapter of the FortiOS 7.4 Administration Guide for the exact command and default before changing it.

Keep a reserved management interface

So you can still reach each physical unit individually after clustering (essential for patching and troubleshooting), reserve a management interface out of the HA sync:

config system ha
    set ha-mgmt-status enable
    config ha-mgmt-interfaces
        edit 1
            set interface "mgmt"          # your dedicated mgmt port
            set gateway <mgmt-gateway-ip>
        next
    end
end

Confirm the exact sub-fields on your build with config ha-mgmt-interfaces → set (tab-complete) if your model differs — the reserved-management feature is standard but the available fields track the firmware version.

Configure the secondary unit

On the second unit, set the same group-name, mode, password, hbdev, and session-pickup, but give it a lower priority so the first unit is preferred:

config system ha
    set group-name "MyClusterName"
    set mode a-p
    set password <the-same-shared-secret>
    set hbdev "port3" 100 "port4" 100
    set session-pickup enable
    set override disable
    set priority 100                      # lower than the primary's 200
    set monitor "port1" "port2"
end

When you commit this and the heartbeat links are up, the units negotiate. The unit that becomes primary synchronizes its full config to the other, which then reboots into the cluster. From this point, manage the cluster from the primary — changes replicate automatically.

Verify it worked

From the CLI of the cluster (you land on the primary):

get system ha status

This shows both members, which is primary/secondary, the sync state, and the heartbeat interface status. You want to see both units listed and the configuration reported in sync.

For a deeper look at negotiation and heartbeat:

diagnose sys ha status

To confirm both units hold an identical config (checksums must match across members):

diagnose sys ha checksum cluster

In the GUI, System > HA shows both members with their roles, serial numbers, and health — the fastest at-a-glance check.

To open a session directly on the secondary unit (for example, to check its firmware) without cabling to it, use execute ha manage from the primary CLI — run it with no arguments first to list the available member index and login syntax, then supply those values.

Test the failover

In your maintenance window, prove it actually fails over before you trust it:

1. Watch a continuous ping through the firewall from a client.
2. Physically power off or pull the WAN/monitored cable on the primary.
3. The secondary should take over within a few seconds; your ping recovers after a brief loss.
4. Restore the primary. With override disable, the secondary keeps the primary role — that is expected. Run get system ha status again to confirm the recovered unit rejoined as secondary and re-synced.

Undo / roll back

To dissolve the cluster, on each unit set the HA mode back to standalone:

config system ha
    set mode standalone
end

Then disconnect the heartbeat cables and restore the pre-change config backup you took at the start if you need each unit's original standalone configuration back. Because forming the cluster overwrote the secondary's config, that backup is the only way to get its original settings back — which is exactly why the safety note told you to take it first.