When a FortiGate HA pair shows Not Synchronized, production traffic can still be flowing through the primary. The immediate question is whether the secondary has the configuration it would need to take over. Start by identifying the exact scope, table, and object that disagree. That gives you evidence to decide whether to correct configuration drift, recalculate a checksum, or investigate cluster health.
This guide uses CLI commands for an FGCP cluster. Run the initial checks from an administrative session with access to both members and the relevant VDOMs. The examples use an active-passive pair, with VDOM-specific configuration in root.
1. Confirm both members are present and on the same build
On the primary, start with:
get system ha status
get system statusRecord the cluster members, their serial numbers and roles, configuration status, and heartbeat interface statistics. Check the member index before opening the peer’s CLI. For example, if the secondary is listed at index 1 and your administrator account is named admin:
execute ha manage 1 admin
get system status
exitCompare the exact FortiOS build on both units. If the peer is missing, heartbeat errors are increasing, or the firmware builds differ outside an expected upgrade window, investigate that first. After an upgrade, confirm that the upgrade process has completed before treating a mismatch as configuration drift.
Fortinet – Check HA synchronization status · Fortinet – HA CLI troubleshooting commands
2. Identify which configuration scope differs
Run this from the primary:
diagnose sys ha checksum clusterCompare the Checksum section for each member. Compare like-for-like fields, such as the primary’s root checksum against the secondary’s root checksum.
| Field | What to compare next |
|---|---|
global | Compare the device-wide configuration tables on each member. |
root or another VDOM name | Compare tables for that specific VDOM. |
all | Use the individual scopes to narrow down the difference. The aggregate alone does not identify the affected table. |
For example, if global matches but root and all differ, start with root. If more than one named scope differs, collect each independently.
3. Compare tables, then find the object
Run the command for the affected scope on each member. These examples show the syntax for a global mismatch and for a mismatch in the root VDOM:
diagnose sys ha checksum show global
diagnose sys ha checksum show rootUse your actual VDOM name in a multi-VDOM deployment. Save the outputs separately and compare the checksum for each named table. If the difference is in firewall.policy within root, drill down one level:
diagnose sys ha checksum show root firewall.policyCompare entries by policy ID. A single different entry can narrow the investigation to one policy in a large rulebase. If your FortiOS build displays the mismatched table under System > HA, use that as a shortcut and confirm the result from both CLI sessions.
Fortinet – Troubleshoot a checksum mismatch in a FortiGate HA cluster
Example: Policy 42 differs in the root VDOM
Suppose the cluster checksums show a root mismatch. The per-table comparison points to firewall.policy, and the per-object output shows a different checksum for policy 42. Run the following on both members from the affected VDOM context:
show full-configuration firewall policy 42Compare the policy’s interfaces, source and destination objects, service, action, inspection profiles, and logging. If policy 42 references a named address or service, compare the referenced object too. A reference with the same name can point to different values if its underlying table is also out of sync. Use the approved configuration or change record to determine the intended values before making any correction.
4. Choose the recovery step based on what you found
- The synchronized configuration differs. Back up the member configurations and review the intended values against the change record. Apply a targeted correction through the approved configuration workflow. For a table-specific issue, check Fortinet guidance for that table and build before editing the secondary or forcing synchronization.
- The configuration matches, but the checksum still differs. Preserve the before-state and use the Fortinet-documented checksum recalculation on the affected members. Recheck the cluster and object afterward. Recalculation recomputes the checksum and does not copy configuration between members.
- The mismatch persists or returns. Collect the before-and-after checksums, exact builds, HA status, the affected table or object, and timestamps. If the difference started after an upgrade, package update, or configuration deployment, include that timing in the TAC case. Keep process restarts and forced failover under the production change procedure.
diagnose sys ha checksum recalculateIf the table is vpn.certificate.ca, compare the certificate-bundle version reported by diagnose autoupdate versions on each unit before changing certificate configuration. Fortinet documents package-version differences as a troubleshooting lead for this table.
Fortinet – HA checksum mismatch procedure
5. Verify the cluster is back in sync
Run get system ha status and diagnose sys ha checksum cluster again. Confirm all expected members report in-sync and that the affected scope now matches. If you isolated a table or policy, rerun its checksum check. Recheck after the next approved configuration change if the issue was intermittent.
Configuration synchronization and traffic continuity are separate checks. Verify application traffic if the incident affected users, and use a planned failover test if you need to validate takeover behavior.
Frequently asked questions
Does an HA checksum mismatch mean the heartbeat is down?
A pair can still see both members over the heartbeat links while their configuration checksums differ. Check membership and heartbeat statistics first, then compare the configuration checksums.
Can I start with a reboot or forced synchronization?
Collect the scope, table, and object details first if the units are responsive. That preserves the evidence and helps you choose the right recovery procedure for the affected configuration.
What if the mismatch is in a VDOM other than root?
Use that VDOM name in the checksum command and inspect the actual object in that VDOM’s context on both members.
For a related diagnostic workflow, see FortiGate Conserve Mode: What to Check Before You Reboot.