Technical Tip: How to Manage FortiGate HA Clusters via FortiManager
Description
This article provides a comprehensive guide to managing FortiGate High Availability (HA) clusters using FortiManager.
It covers the process of adding HA clusters to FortiManager, explains the key behavioral differences between Active-Passive and Active-Active HA modes, especially regarding traffic processing and log sources, and details how configuration synchronization is handled.
The article also addresses common challenges such as failover behavior, HA cluster role promotion, and known issues related to FGFM tunnels and configuration drift. Practical troubleshooting tips and best practices are included to help administrators maintain a reliable HA environment.
Scope
FortiManager, FortiGate.
Solution
FortiManager connects to the HA cluster’s primary unit via FGFM and pushes configuration changes there, which are then synced automatically to secondary units. While it only interacts with the primary regardless of HA mode, understanding key differences between Active-Passive and Active-Active, like traffic handling and log sources, is essential for effective management. This setup centralizes control and simplifies failover and role promotion.
Topology Example:
 
Adding a FortiGate HA Cluster to FortiManager:
-
In FortiManager, go to Device Manager.
-
Select Add Device/Discover Device and provide the IP address of the primary FortiGate in the HA cluster.
-
Enter valid administrator credentials with API/FGFM access.
-
FortiManager will automatically detect the HA cluster and retrieve information about the secondary units.
-
The entire HA cluster will be added as one logical device in FortiManager.
Alternative Method:
The FortiGate HA cluster can also be added to FortiManager using the Fabric Connector, initiated from the primary FortiGate unit. This method is suitable for environments where Security Fabric integration is in use.
Important:
Do not add secondary HA members manually. FortiManager does not support managing HA peers separately.
FortiManager and HA Cluster Interaction:
-
FortiManager communicates only with the current primary unit using FGFM (port 541).
-
Configuration changes are pushed to the primary and automatically synchronized to all secondary units.
-
HA member roles and sync status are visible in Device Manager > System > HA.
Active-Active Clusters, Key Differences:
| Area | Active-Passive | Active-Active |
|---|---|---|
| FortiManager Management | Primary only | Primary only |
| Traffic Processing (Network) | One node | Multiple nodes |
| Log Sources | Single unit | Possibly multiple |
| Config Install Path | FortiManager → Primary → Sync | FortiManager → Primary → Sync (same behavior) |
- FortiManager only interacts with the primary FortiGate in an HA cluster, even in Active-Active mode.
- FortiManager detects HA settings automatically from the FortiGate cluster but does not manage or control HA configuration.
- To change HA settings, configure them directly on the real FortiGate devices and import the configuration into FortiManager.
- Changes to the HA settings in FortiManager using CLI templates or scripts will only update the device database in FortiManager. These HA settings will NOT be pushed to the real FortiGate when an install is performed.
Based on the table above, it is essential to understand the key differences between Active-Passive and Active-Active High Availability (HA) modes for effective management and troubleshooting.
Traffic Processing:
- In Active-Passive, only the primary unit handles traffic; secondaries wait in standby. It’s simpler but can leave resources unused.
- In Active-Active, multiple units share the traffic load, boosting performance but making sync and config more complex.
Log Sources:
- Active-Passive logs come from the single active unit, which makes log handling easier.
- Active-Active logs originate from multiple active units, requiring careful aggregation and correlation.
Since FortiManager communicates only with the primary unit, it is important to monitor HA status to ensure the correct unit is primary and reachable. These operational differences impact failover handling, performance management, and log collection. Awareness of these factors supports informed decisions when promoting HA members or troubleshooting synchronization issues.
Synchronizing HA Cluster Configuration:
FortiManager does not include a dedicated 'resync' option for HA clusters. Configuration changes made on the primary unit are automatically synchronized across all members; however, depending on policy settings, manual synchronization on the FortiGate device may be required occasionally.
On the primary FortiGate, execute:
execute ha synchronize start
 
Promote the HA cluster node via FortiManager.-
In Device Manager, select the HA cluster.
-
Navigate to Edit -> HA.
-
Select Promote next to the desired secondary unit. (Make sure to update the FortiGate 'Admin User' and 'Password', otherwise the HA role promotion will not be updated.) Refers to the related article to get more information on how to promote a HA cluster node from FortiManager.
 
Caution:
FortiManager may still use the original FGFM tunnel until it re-establishes a new session. A brief management disconnect may occur.
Use the following CLI commands on FortiManager during 'Promote' to have more details about the process:
diagnose debug application fgfm 255
diagnose debug enable
During a failover (or 'promote') operation, the following technical points should be verified:
- Tunnel Reconnected: After promotion, FGVM08TM2200xxx2 reconnects to FMGVMSTM220xxxx via FGFM tunnel (169.254.x.x assigned).
- TLS Handshake OK: TLS 1.3 handshake completes, certs validated (fortinet-subca2001 matched).
- HA & Sync: Device in ha_mode=1, group fortinet, and config status set to IN_SYNC after reconnect.
- Scripts & Checksums: Health scripts pushed; matching checksums confirm config consistency.
- Tunnel Lifecycle: Tunnel gets cleaned up and reestablished with session IDs rotating (as expected).
Known Issues and Best Practices.
Usual problems:
-
FGFM tunnel disruption after failover.
-
Out-of-sync HA configurations.
-
Manual addition of secondary units (causes duplication and config drift).
Troubleshooting Quick Reference:
| Problem | Cause | Suggested Fix |
|---|---|---|
| FortiManager still talks to old primary after failover | FGFM tunnel not re-established | Restart FGFM daemon or wait for reconnection |
| Config changes not reflected on secondaries | HA out of sync | Run CLI sync command on primary |
| Duplicate cluster members in FortiManager | Secondary added manually | Remove and re-add the cluster properly |
Additional Note:
-
Always perform full configuration installs to HA clusters. (To ensure all units in the HA cluster stay fully synchronized and avoid config drift).
-
Use HA promotion only during maintenance windows.
-
Monitor HA status using FortiGate CLI:
get system ha status
Below is an example after a failover procedure (Promote operation achieved from FortiManager):
 
After an HA failover, check the following regarding priority (above output results):
-
Override: Ensure it’s enabled if priority-based selection is intended.
-
Priority values: Confirm the primary unit has the highest priority.
-
Failover reason: Check logs or get system HA status to see if the new primary was selected due to priority.
Note:
If the wrong unit becomes primary, adjust priorities or disable override on the FortiGate side.
The second command that can be used: 'diagnose sys ha checksum show' <----- Useful to verify the integrity and synchronization status of the HA cluster configuration.
 
Related documents:
Technical Tip: How to promote FortiGate HA cluster unit via FortiManager
Technical Tip: FortiManager fails to promote secondary cluster member to primary