FortiGate HA — FGCP Active-Passive and Active-Active

The one-sentence mental model

FGCP makes two (up to four) identical FortiGates behave as one virtual firewall. They share the same MAC on user-facing interfaces, elect one as primary, and mirror configuration + session state so a failure is invisible to the traffic that was already flowing.

Requirements

• Same model. 100F pairs with 100F. No mixing.
• Same firmware. Both boxes on the same FortiOS build.
• Same license. FortiGuard subscriptions must align.
• Dedicated heartbeat links. At least one; two recommended.
• Same interface types + counts. Ports must match physically.

Heartbeat

FGCP uses a proprietary Layer-2 protocol (ethertype 0x8890, 0x8891, 0x8893) on dedicated heartbeat interfaces:

• Interval: 200 ms default. Miss 6 → member declared dead.
• Recommended: 2 heartbeat interfaces on different physical NICs, cross-connected between members.
• Never share a heartbeat interface with data traffic.

The election

When members boot, they compare (in order):

1. Override enable + higher priority — if override is on, the higher-priority unit wins even if the other was primary first.
2. Number of monitored interfaces up — a member missing an interface can’t be primary.
3. HA uptime — longer up wins (stability).
4. Priority — higher wins (default 128).
5. Serial number — higher wins (final tie-breaker).

Watch out: without override, whoever booted first stays primary — even after the “preferred” unit comes back. Turn override on if you want a specific unit to always be primary when healthy.

Active-Passive

Traffic flows only through the primary. Secondary syncs config + sessions and stands by.

Config sketch:

config system ha
  set group-name "hq-cluster"
  set mode a-p
  set password SharedSecret
  set hbdev "ha1" 50 "ha2" 40
  set session-pickup enable
  set override enable
  set priority 200               # this box preferred
end

Session pickup — must be enabled or existing sessions drop on failover. Override + priority — makes the box with priority 200 always the primary after a failure.

Active-Active

All members forward. The primary receives all inbound frames on the shared MAC, then distributes new sessions to secondaries by hash. Return traffic comes back through the same member (via session table).

Modes:

• Hash-based (default) — src-ip-dst-ip or src-ip only. New sessions distributed.
• UTM offload — primary hands off IPS / AV inspection to a secondary. Rarely tuned to; A-A is mostly historical.

Cons: harder troubleshooting (which member is inspecting this flow?), config drift risk during maintenance windows.

HA MAC and the “virtual” cluster

On user-facing interfaces, all members share the same virtual MAC (derived from the group-id). Upstream switch sees one MAC. Failover doesn’t require ARP flush — the new primary just starts answering.

Downside: if two clusters accidentally share the same group-id on the same L2, both use the same MACs → chaos. Change group-id if you have multiple clusters on shared VLANs.

Split-brain avoidance

Split-brain = both members think they’re primary. Happens when all heartbeat links die but data links stay up. Both start responding to the shared MAC → duplicate frames, session sync stops, traffic breaks.

Mitigations:

• Multiple heartbeat interfaces. Always. On different NICs.
• HA reserved management interface. Even if data + HB die, you have a separate path to reach one box.
• Monitor interfaces so a member with dead uplinks demotes itself before winning the election.

Verification

get system ha status                   # who's primary, sync state, HB
diagnose sys ha status                 # detailed member info
diagnose sys ha checksum show          # config checksums must match
diagnose sys ha reset-uptime           # force re-election (careful)
execute ha manage 1                    # SSH into the secondary

checksum show is the single most useful command: if the config checksum doesn’t match across members, config sync is broken. Common cause: someone changed config on the secondary directly (only ever change on primary).

Common exam / real-world mistakes

1. Sharing HB with data traffic. Ethertypes collide, HB gets dropped under load, split brain follows. Always dedicate.
2. Forgetting session-pickup. Failover works but every existing TCP session drops. Users see hangs / reconnects. Turn it on unless you have a specific reason not to.
3. Skipping override. You expected the “primary” unit to always be primary. Without override, whoever booted first stays.
4. Changing config on the secondary. Config sync only flows primary → secondary. Direct edits on the secondary are silently overwritten (or worse, cause checksum mismatch until fixed).
5. Ignoring monitor interfaces. If the box’s WAN uplink dies but no interfaces are monitored, HA doesn’t fail over — traffic just black-holes.

Cheat strip

Mode         A-P (default, simple)  |  A-A (hash distribution, rare)
Members      2–4 identical FortiGates
Heartbeat    dedicated links, 200 ms × 6 = 1.2 s detection
Election     override+prio  →  monitor state  →  HA uptime  →  priority  →  SN

Session sync  session-pickup enable  (or existing flows drop)
Override      priority   (higher wins after recovery)
Monitor       interfaces failing = demote self
HB reserved   separate mgmt interface for split-brain recovery

Verify       get system ha status
             diagnose sys ha checksum show    (config drift)
             execute ha manage <N>            (SSH secondary)