FortiGate High Availability (HA)
FortiGate Technical Deep-Dive | FortiOS 7.4 / 7.6
How It Works | HA Modes | Use Cases | Step-by-Step Configuration | ISSU Upgrade | Best Practices
Applicable: FortiGate 60F | 100F | 200F | 400F | 600F | 1000F | 2600F and above
Table of Contents
- What Is FortiGate High Availability?
- How FortiGate HA Works — Heartbeat, Election, Sync & Failover
- HA Modes: Active-Passive, Active-Active, FGSP & Virtual Clustering
- Real-World Use Cases
- Prerequisites & Network Planning
- Step-by-Step Configuration (CLI & GUI)
- ISSU — Firmware Upgrade Without Downtime
- Verification & Monitoring Commands
- Troubleshooting Guide
- Best Practices
- Complete CLI Configuration Summary
1. What Is FortiGate High Availability?
High Availability (HA) in FortiGate is a clustering technology that links two or more FortiGate units together so they operate as a single logical firewall. If one unit fails — due to hardware fault, software crash, power loss, or link failure — another unit in the cluster takes over automatically, with minimal or zero disruption to active network traffic.
FortiGate HA is implemented using the Fortinet Clustering Protocol (FGCP) for traditional deployments, and FGSP (FortiGate Session Life Synchronization Protocol) for active-active deployments behind external load balancers. This guide focuses primarily on FGCP, which covers the vast majority of FortiGate HA deployments.
Why FortiGate HA Matters
❌ Eliminates Single Points of Failure
No single firewall failure can take down your network security perimeter.
✅ Meets 99.99% SLAs
Sub-second failover supports the strictest uptime requirements for internet and data center gateways.
Seamless Session Survival
Established TCP sessions and VPN tunnels survive a hardware failure transparently.
️ Simple Management
The cluster appears as a single device — no doubling of management complexity.
HA Key Terminology
2. How FortiGate HA Works
2.1 The Heartbeat Link
The heartbeat link is the backbone of FortiGate HA — a dedicated physical connection (or VLAN) between cluster members used exclusively for HA communication. FortiGate sends heartbeat packets every 200ms by default. If a unit misses a configurable number of consecutive heartbeat packets from the primary, it triggers a failover election.
Minimum: one heartbeat interface per cluster pair. Best practice: two heartbeat links on different physical interfaces for redundancy.
Heartbeat traffic is tagged with VLAN 999 by default — do not place other traffic on this link.
Heartbeat link carries: configuration synchronization, session table sync, and cluster management traffic.
Heartbeat interfaces should be directly connected between cluster members — no intervening switches unless absolutely necessary.
2.2 Primary Election
When the cluster forms or a failover occurs, FGCP elects a primary unit using the following criteria in order of priority:
Key Insight: If a monitored interface goes down on the primary, the secondary immediately has more UP monitored ports and wins the election — even if the primary is still running. This is the primary failover trigger for link failure scenarios.
2.3 Configuration Synchronization
All configuration changes made on the primary unit are automatically synchronized to all secondary units in real time. This includes:
Policies & Rules
- Firewall policies & NAT rules
- VPN configurations
- Routing tables & SD-WAN rules
Security & Auth
- User & device auth databases
- IPS, AV, web filter signatures
- IPsec SA & SSL-VPN states
⚙️ System Settings
- Interfaces, DNS, NTP
- System-wide configurations
- All policy objects & profiles
⚠️ Exception: Each unit retains its own individual management IP, hostname, and HA-specific settings. These are NOT synchronized — they must be configured independently on each unit.
2.4 Session Synchronization
Session sync is what makes FortiGate failover transparent to users. The primary unit continuously replicates its active session table to secondary units over the heartbeat link. When a failover occurs:
Secondary detects primary failure (missed heartbeats exceed threshold)
Secondary promotes itself to primary via FGCP election
New primary sends Gratuitous ARP on all interfaces to update upstream ARP caches
New primary uses virtual MAC addresses — upstream switches do not need to relearn MAC-to-port mappings
Existing sessions resume using the synchronized session table — TCP connections and VPN tunnels survive
⚠️ Session Sync Limitation: UDP and ICMP sessions may not survive failover as seamlessly as TCP. IPsec IKE SAs are synchronized but may require re-negotiation depending on timing.
2.5 Failover Timeline
✅ Result: End-to-end failover typically completes in 1–3 seconds. Most TCP applications recover transparently. VoIP calls may experience a brief audio gap but rarely drop entirely.
3. FortiGate HA Modes
FortiGate supports two primary HA clustering modes under FGCP, plus a standalone session-sync mode (FGSP). Choosing the right mode depends on your traffic pattern, failover requirements, and whether you need active-active throughput scaling.
Active-Passive (A-P) — Recommended for Most Deployments
Active-Passive is the most common FortiGate HA mode. One unit (primary) processes all traffic. The secondary unit sits idle, receiving config and session sync, ready to take over instantly if the primary fails.
| Attribute | Detail |
|---|---|
| Traffic Processing | Primary handles 100% of traffic; secondary is idle (standby) |
| Failover | Sub-second; secondary promotes and resumes sessions from sync table |
| Session Sync | Full session table replicated to secondary continuously |
| Complexity | Low — simplest HA mode to configure and troubleshoot |
| Use Case | Standard enterprise firewall, branch, data center perimeter, VPN gateway |
✅ Recommended For: Most deployments. Simplest to operate, easiest to troubleshoot, and provides full session continuity on failover. Choose A-P unless you specifically need throughput scaling.
Active-Active (A-A) — High-Throughput / CPU-Bound Workloads
Active-Active mode allows both units to process traffic simultaneously by distributing sessions across cluster members. The primary receives all traffic and uses a load-balancing algorithm to forward sessions to secondary units for processing.
| Attribute | Detail |
|---|---|
| Traffic Processing | Primary receives all traffic; distributes sessions to secondary via HA link for processing |
| Throughput | Higher aggregate throughput — both CPUs handle inspection workload |
| Complexity | Higher — asymmetric routing possible; requires careful design |
| Use Case | High-throughput environments where single unit cannot handle peak CPU load |
⚠️ A-A Caution: Active-Active does NOT double your throughput in all scenarios. The primary still receives all traffic and distributes it — creating a bottleneck at the primary's interfaces. A-A primarily helps with CPU-bound workloads like SSL inspection. For interface bandwidth scaling, use ECMP or SD-WAN instead.
Active-Passive vs Active-Active — Quick Comparison
FGSP — Session Sync Without FGCP (Behind External Load Balancers)
FGSP is a peer-based session sync mechanism for deployments where FortiGate units are placed behind an external load balancer (F5, Citrix ADC, cloud load balancer). Unlike FGCP, FGSP units operate completely independently — each has its own routing, policies, and management.
No primary/secondary concept — all units are equal peers
No heartbeat-based failover — the external load balancer handles failover detection
Each FortiGate has its own independent configuration — no auto-sync
Used in cloud deployments (Azure, AWS) and carrier-grade / large data center environments requiring N+1 or N+M redundancy
Virtual Clustering (VDOM-Based HA)
When VDOMs are enabled, different VDOMs can have different primary units — FortiGate-A is primary for VDOM-1 while FortiGate-B is primary for VDOM-2. This provides active-active load distribution at the VDOM level. Requires VDOM licenses; typically used in MSSP or large enterprise multi-tenant environments.
4. Real-World Use Cases
4.1 — Internet Edge / Perimeter Firewall
The most common HA use case. Two FortiGate units deployed at the network perimeter, connected to ISP links and the internal LAN/DMZ. Active-Passive HA ensures the internet gateway is always available — if the primary fails due to hardware fault, power outage, or ISP link drop, the secondary takes over within seconds and internet access resumes for all users without anyone noticing.
4.2 — Data Center Firewall
A pair of FortiGate units (often 400F, 1000F, or 2600F) sits at the data center core or perimeter. HA ensures that server-to-server traffic inspection and data center internet access continue uninterrupted during planned maintenance (firmware upgrades via ISSU) or unexpected failures.
4.3 — SD-WAN Hub Redundancy
FortiGate SD-WAN hub sites benefit significantly from HA. The hub aggregates VPN tunnels from all branch spokes. Without HA, a hub failure brings down all branches simultaneously. With HA, the secondary hub takes over and spoke VPN tunnels re-establish automatically, restoring connectivity to all branches within seconds.
4.4 — VPN Gateway Redundancy
FortiGate HA synchronizes IPsec SA (Security Association) state to the secondary, so VPN tunnels survive failover. Remote users may experience a brief reconnection, but the tunnel re-establishes using the same virtual IP and policies — no user reconfiguration required.
4.5 — Compliance-Driven Uptime (PCI-DSS, HIPAA, ISO 27001)
Organizations subject to PCI-DSS, ISO 27001, HIPAA, or financial sector regulations often require 99.99% uptime (≈52 minutes downtime per year). FortiGate HA with sub-second failover and regular testing makes meeting these SLAs achievable without complex architecture.
️ 4.6 — Planned Maintenance Without Downtime (ISSU)
FortiGate HA supports ISSU (In-Service Software Upgrade), which upgrades cluster members one at a time while the other continues processing traffic. This allows firmware upgrades during business hours without scheduling a maintenance window — a significant operational benefit for 24/7 environments.
5. Prerequisites & Network Planning
5.1 Hardware Requirements
Both FortiGate units must be identical model — same hardware revision, same NIC modules
Both units must run the same FortiOS firmware version before forming the cluster
Both units must have the same FortiGuard subscription licenses (HA license is included in base FortiOS)
Dedicated HA heartbeat cables — direct copper/fiber connection between units (two recommended)
⚠️ Critical: FortiGate HA will NOT form between different models (e.g., a 100F and a 200F). Both units must be the exact same model. FortiOS will refuse to form the cluster and log an error if models do not match.
5.2 Network Planning Checklist
6. Step-by-Step Configuration (CLI & GUI)
The following steps configure a two-unit FortiGate HA cluster in Active-Passive mode using FortiOS 7.4. Configure the primary unit first, then the secondary.
Before You Start: Ensure both units are running the same FortiOS firmware. Connect heartbeat cables before enabling HA. Have console access available in case management access is temporarily disrupted during cluster formation.
Configure HA on the Primary Unit (FortiGate-A)
Via GUI: System → HA → Set Mode: Active-Passive | Group Name: FG-HA-CLUSTER | Password: HAclusterP@ss | Priority: 200 | Heartbeat Interfaces: port9 & port10 | Enable Session pickup & Override → OK
Via CLI (Primary — FortiGate-A):
set mode a-p
set group-id 1
set group-name FG-HA-CLUSTER
set password HAclusterP@ss
set priority 200
set hbdev port9 50 port10 50
set session-pickup enable
set session-pickup-connectionless enable
set override enable
set monitor port1 port2 port3
end
Note: In hbdev syntax, the number after the interface name is the heartbeat priority. Use equal values (50/50) for both heartbeat links to share load.
Configure HA on the Secondary Unit (FortiGate-B)
set mode a-p
set group-id 1
set group-name FG-HA-CLUSTER
set password HAclusterP@ss
set priority 128 ! Lower than primary
set hbdev port9 50 port10 50
set session-pickup enable
set session-pickup-connectionless enable
set override enable
set monitor port1 port2 port3
end
Once both units have HA configured with matching group-name and password, they will discover each other over the heartbeat link, elect a primary (FortiGate-A wins due to priority 200 vs 128), and synchronize configuration automatically.
Configure Individual Management IPs
Management IPs allow independent SSH/GUI access to each unit. These are NOT synchronized and must be configured separately on each unit.
config system ha
config ha-mgmt-interfaces
edit 1
set interface mgmt
set dst 0.0.0.0/0
set gateway 10.0.0.254
next
end
end
config system interface
edit mgmt
set ip 10.0.0.10 255.255.255.0
set allowaccess https ssh ping
next
end
! On SECONDARY (FortiGate-B) — different IP:
config system interface
edit mgmt
set ip 10.0.0.11 255.255.255.0
set allowaccess https ssh ping
next
end
Configure Interface Monitoring
Interface monitoring tells the HA cluster which interfaces to watch. If a monitored interface on the primary goes DOWN, the secondary immediately wins the election — triggering failover.
set monitor port1 port2 port3
! port1 = WAN1, port2 = WAN2, port3 = LAN
! Add all interfaces where a link failure should trigger failover
end
Tip: Do NOT monitor heartbeat interfaces — if a heartbeat cable fails, you do not want a failover. Monitor only the data-plane interfaces that carry production traffic.
Verify Cluster Formation
get system ha status
! Expected output on PRIMARY:
! HA Health Status: OK
! Mode: HA A-P
! Group: FG-HA-CLUSTER
! Master: FG200F-A (prio=200, state=work)
! Slave: FG200F-B (prio=128, state=standby)
diagnose sys ha status ! Detailed diagnostics
diagnose sys ha checksum show ! Check config sync
diagnose sys session stat ! Verify session sync
Step 6 (Optional) — Switch to Active-Active Mode
set mode a-a
! Load balance methods: hub | arp-monitor | ip | ipport
set load-balance-all enable
end
7. ISSU — Firmware Upgrade Without Downtime
ISSU (In-Service Software Upgrade) allows you to upgrade FortiOS on a cluster without taking down traffic. The cluster upgrades one unit at a time while the other continues processing traffic.
ISSU Upgrade Procedure
Verify current cluster health: get system ha status — both units must show OK
Download target firmware from support.fortinet.com and verify checksum
Upload firmware via GUI: System → Firmware → Select "Upgrade HA cluster member by member"
FortiGate upgrades the secondary first — secondary reboots, primary continues processing traffic
Secondary rejoins cluster on new firmware — cluster runs mixed versions briefly
FortiGate triggers controlled failover — secondary (now on new firmware) becomes primary
Former primary reboots and upgrades — rejoins as secondary on new firmware
Cluster returns to normal — both units on new firmware. Verify: get system ha status
⚠️ ISSU Warning: Do not interrupt the upgrade process once started. Always have console access available. Confirm ISSU compatibility in the FortiOS release notes — some version jumps require intermediate upgrades and cannot use ISSU directly.
8. Verification & Monitoring Commands
get system ha status
diagnose sys ha status
! ── Check config sync between members ───────────────────────
diagnose sys ha checksum show
diagnose sys ha checksum cluster
! ── Session sync statistics ──────────────────────────────────
diagnose sys session stat
diagnose sys ha dump-by session
! ── Heartbeat interface stats ────────────────────────────────
diagnose sys ha heartbeat
! ── Force failover for testing (from primary) ────────────────
diagnose sys ha reset-uptime
! Resets primary uptime — secondary wins next election
! ── Check monitored interface status ─────────────────────────
diagnose sys ha port-stats
! ── Force config resync from primary ─────────────────────────
execute ha synchronize start
! ── View HA logs ─────────────────────────────────────────────
execute log filter field type event
execute log display
GUI Monitoring Locations
System → HA — Shows cluster members, role (primary/secondary), sync status, and uptime
Dashboard → HA Status widget — Real-time heartbeat health and sync state
System → HA — Click on secondary unit to open its GUI directly via the primary
Log & Report → System Events — Filter for 'ha' to see failover and sync events
9. Troubleshooting Guide
10. Best Practices
️ Design
Always use two heartbeat interfaces on separate physical NICs — single heartbeat failure causing split-brain is a critical risk
Connect heartbeat interfaces with direct cables — no shared switches
Use Active-Passive for most deployments — simpler, more reliable, better session continuity
Configure dedicated management IPs per unit from day one
Use UPS on both units connected to different power circuits
️ Configuration
Set primary priority to 200 and secondary to 128 — do not leave both at default 128
Enable HA override on both units — ensures intended primary reclaims its role after rebooting
Enable session-pickup and session-pickup-connectionless for maximum session survival
Use a strong, unique HA group password — anyone knowing the password could join the cluster
Never make config changes directly on the secondary — always configure on primary and let sync distribute
Operations
Test failover in a maintenance window before go-live — shut primary, confirm secondary takes over and sessions resume
Test by shutting a monitored interface — not just powering off the unit. Interface failure is the most common real-world trigger
Monitor HA health continuously via SNMP traps or Syslog to your SIEM
Run diagnose sys ha checksum cluster weekly — config drift is a silent risk
Always use ISSU for firmware upgrades — never upgrade both units simultaneously
Keep spare FortiGate hardware (same model) on hand — if secondary fails, you are operating without redundancy
11. Complete CLI Configuration Summary
Primary Unit (FortiGate-A) — Full HA Config | FortiOS 7.4
! FORTIGATE HA — PRIMARY UNIT (FortiGate-A) FULL CONFIG
! FortiOS 7.4 | Active-Passive Mode
! ============================================================
! --- HA Core Settings ---
config system ha
set mode a-p
set group-id 1
set group-name FG-HA-CLUSTER
set password HAclusterP@ss
set priority 200
set hbdev port9 50 port10 50
set session-pickup enable
set session-pickup-connectionless enable
set override enable
set monitor port1 port2 port3
set ha-uptime-diff-margin 300
set hello-holddown 20
set arps 5
set arps-interval 8
! --- Management interface for direct access to this unit ---
config ha-mgmt-interfaces
edit 1
set interface mgmt
set dst 0.0.0.0/0
set gateway 10.0.0.254
next
end
end
! --- Management IP (unique per unit, NOT synced) ---
config system interface
edit mgmt
set ip 10.0.0.10 255.255.255.0
set allowaccess https ssh ping
next
end
Secondary Unit (FortiGate-B) — Full HA Config | FortiOS 7.4
! FORTIGATE HA — SECONDARY UNIT (FortiGate-B) FULL CONFIG
! FortiOS 7.4 | Active-Passive Mode
! ============================================================
config system ha
set mode a-p
set group-id 1
set group-name FG-HA-CLUSTER
set password HAclusterP@ss
set priority 128 ! Secondary = lower priority
set hbdev port9 50 port10 50
set session-pickup enable
set session-pickup-connectionless enable
set override enable
set monitor port1 port2 port3
set ha-uptime-diff-margin 300
set hello-holddown 20
set arps 5
set arps-interval 8
config ha-mgmt-interfaces
edit 1
set interface mgmt
set dst 0.0.0.0/0
set gateway 10.0.0.254
next
end
end
! --- Management IP (different from primary) ---
config system interface
edit mgmt
set ip 10.0.0.11 255.255.255.0
set allowaccess https ssh ping
next
end
⚡ Key Verification Commands — Quick Reference
diagnose sys ha status ! Detailed HA state
diagnose sys ha checksum cluster ! Config sync verification
diagnose sys ha heartbeat ! Heartbeat link stats
diagnose sys session stat ! Session sync stats
diagnose sys ha port-stats ! Monitored interface status
execute ha synchronize start ! Force config resync from primary
diagnose sys ha reset-uptime ! Force controlled failover (testing)
Ready to Deploy FortiGate HA?
Refer to the official Fortinet documentation for your specific FortiOS version before production deployment.
Fortinet Docs ↗Tags
