Troubleshooting HA configuration synchronization issues on FortiGate and FortiProxy

1. Confirm that both HA members run the same firmware.

Run the following command on both units:

get system status

Access the secondary member through the HA CLI if necessary. In a multi-VDOM deployment, run global-level HA commands from config global mode.

2. Review HA health and synchronization state.

In the GUI, open System -> HA. Alternatively, run:

get system ha status

This output provides HA health, operating mode, group, uptime, failover or primary-selection reason, session pickup settings, configuration state, resource usage, heartbeat statistics, monitored-interface statistics, member roles, cluster indexes, and vcluster information.

Example:

HA Health Status: OK
Model: FortiGate-VM64-KVM
Mode: HA A-P
Group: 9
Debug: 0
Cluster Uptime: 14 days 5:9:44
Cluster state change time: 2019-06-13 14:21:15
The Primary is selected using the following:
<date:02> FGVMXXXXXXXXXX44 is selected as the Primary because it has the largest value of uptime.
<date:01> FGVMXXXXXXXXXX46 is selected as the Primary because it has the largest value of uptime.
<date:00> FGVMXXXXXXXXXX44 is selected as the Primary because it has the largest value of override priority.
ses_pickup: enable, ses_pickup_delay=disable
override: disable
Configuration Status:
FGVMXXXXXXXXXX44(updated 3 seconds ago): in-sync
FGVMXXXXXXXXXX46(updated 4 seconds ago): in-sync
System Usage stats:
FGVMXXXXXXXXXX44(updated 3 seconds ago):
sessions=42, average-cpu-user/nice/system/idle=0%/0%/0%/100%, memory=64%
FGVMXXXXXXXXXX46(updated 4 seconds ago):
sessions=5, average-cpu-user/nice/system/idle=0%/0%/0%/100%, memory=54%
HBDEV stats:
FGVMXXXXXXXXXX44(updated 3 seconds ago):
port8: physical/10000full, up, rx-bytes/packets/dropped/errors=2233369747/7606667/0/0, tx=3377368072/8036284/0/0
FGVMXXXXXXXXXX46(updated 4 seconds ago):
port8: physical/10000full, up, rx-bytes/packets/dropped/errors=3377712830/8038866/0/0, tx=2233022661/7604078/0/0
MONDEV stats:
FGVMXXXXXXXXXX44(updated 3 seconds ago):
port1: physical/10000full, up, rx-bytes/packets/dropped/errors=1140991879/3582047/0/0, tx=319625288/2631960/0/0
FGVMXXXXXXXXXX46(updated 4 seconds ago):
port1: physical/10000full, up, rx-bytes/packets/dropped/errors=99183156/1638504/0/0, tx=266853/1225/0/0
Primary : Prim-FW, FGVMXXXXXXXXXX44, cluster index = 1
Secondary : Bkup-Fw, FGVMXXXXXXXXXX46, cluster index = 0
number of vcluster: 1
vcluster 1: work 169.254.0.2
Primary : FGVMXXXXXXXXXX44, operating cluster index = 0
Secondary : FGVMXXXXXXXXXX46, operating cluster index = 1

3. Compare cluster checksums.

Run this command and compare the output for every member:

diagnose sys ha checksum cluster

Collecting the output from only one firewall is not sufficient. The command identifies checksum values for the global context and each VDOM. If one VDOM differs, the aggregate all checksum also differs. For example, matching global and root values with a different Cust-A checksum localizes the issue to Cust-A rather than the synchronized contexts.

4. Use the GUI to identify out-of-sync objects.

Go to System -> HA, then place the pointer over the Not Synchronized unit status. The pop-up chart lists objects associated with the mismatch.

5. Map the mismatch to a configuration table.

Run this on both firewalls:

diagnose sys ha checksum test

Use the HA Checksum Table to identify the likely configuration section. Compare the corresponding output from the primary and secondary, including these contexts when indicated:

config system global

config system interface

config system ha

config system console

The two configuration files can be compared in Notepad++ with Ctrl+Alt+C.

6. Drill down into the affected VDOM or global context.

Use:

diagnose sys ha checksum show <vdom_name>

diagnose sys ha checksum show <global>

For the example where Cust-A is the only mismatched VDOM, run:

diagnose sys ha checksum show Cust-A

After identifying the mismatched object, replace <object_name> with its actual name:

diagnose sys ha checksum show Cust-A <object_name>

This narrows the difference to a specific part of the object. Repeat these commands on every member and inspect the corresponding configuration.

Filter checksum output when necessary. For example:

diagnose sys ha checksum show root | grep system

diagnose sys ha checksum show global | grep log

7. Correct system.Interface differences.

A mismatch may appear as different hashes, for example:

system.Interface: aa207297e1e1061002b5054a8b2d25d9

on the primary and:

system.interface: 1c74002d99cdb6acb6efe870b1f11e012a

on the secondary. Collect and compare the following output from both devices:

show system interface

An example is an interface named Test that references port7 on the primary but port8 on the secondary:

config system interface
    edit Test
        set interface port7
end

Log in to the secondary, unset the incorrect port first, and then set the correct port. Setting the intended port without first unsetting the existing value can produce errors.

8. Recalculate HA checksums when no configuration difference is found.

Run the following on both units to recalculate every checksum:

diagnose sys ha checksum recalculate

To recalculate only one VDOM or the global checksum, use:

diagnose sys ha checksum recalculate [<your_vdom_name> | global]

Without an option, all checksums are recalculated. Specifying a VDOM recalculates only that VDOM; specifying global recalculates the global checksum. The resulting values should match across all cluster members.

9. Run manual synchronization with HA debugging enabled.

Execute:

execute ha synchronize stop

diagnose debug reset

diagnose debug application hatalk -1

The hatalk debug checks heartbeat communication between HA members.

diagnose debug application hasync -1

The hasync debug traces the HA synchronization process.

diagnose debug console timestamp enable

diagnose debug enable

execute ha synchronize start

Stop debugging afterward:

diagnose debug disable

diagnose debug reset

10. Restart HASYNC if debugging shows peer closing the connection.

Run this on both firewalls:

fnsysctl killall hasync

If this does not work—for example, when an external USB device is inserted—an administrator can use:

diagnose sys kill <signal> <pidofhasync>

Check the HASYNC process ID before and after the restart:

diagnose sys process pidof hasync

A changed PID confirms that the process restarted. Repeat manual synchronization with debugging enabled.

11. Collect HA difference logs if synchronization still fails.

Clear and enable HADiff logging, then start synchronization:

diagnose sys ha hadiff log clear

diagnose sys ha hadiff log enable

execute ha synchronize start

Wait several minutes, then read the log:

fnsysctl cat /tmp/hadiff/hadiff.log

On a FortiGate 3301E running FortiOS 7.2.13, a user reported that the file could be listed but reading it failed with Not allowed:

firewall-2 (Cust-A) # fnsysctl ls -l /tmp/hadiff
-rw-r--r--    1 0        0        Fri Jul 17 15:03:02 2026             7570 hadiff.log
drwxr-xr-x    2 0        0        Fri Jul 17 15:03:01 2026               80 master_conf
drwxr-xr-x    2 0        0        Fri Jul 17 14:30:53 2026               40 master_csum
drwxr-xr-x    2 0        0        Fri Jul 17 15:03:02 2026               80 merge_conf
drwxr-xr-x    2 0        0        Fri Jul 17 15:03:02 2026               80 slave_conf
drwxr-xr-x    2 0        0        Fri Jul 17 15:03:01 2026              100 slave_csum

firewall-2 (Cust-A) # fnsysctl cat /tmp/hadiff/hadiff.log
cat: /tmp/hadiff/hadiff.log: Not allowed

Disable HADiff logging and clear its log when finished:

diagnose sys ha hadiff log disable

diagnose sys ha hadiff log clear

12. Check for rejected configuration and storage differences.

Run:

diagnose debug config-error-log read

Identify configuration lines that were not accepted and try to configure the listed item manually.

Run on both units:

diagnose hardware device disk

Disk size and availability must match. If a member reports its log disk as Need format or Not Available, remove that unit from the cluster and format the disk.

Compare storage configuration:

show system storage

The storage-disk size should match on both devices.

Compare WAN optimization storage:

show wanopt storage

The WANOP disk size should also match.

13. Reboot cluster members if they remain out of sync.

Reboot the secondary first. If the issue persists, fail over to the secondary so it becomes primary, and then reboot the new secondary, which was the original primary.

14. As a recovery option, isolate the secondary and restore a cluster backup.

In HA VDOM mode, create the backup from Global mode so that it contains all VDOMs.

1. Back up an existing cluster member using a super_admin account. Confirm that the configuration contains a local super_admin; create one before the backup if none exists.
2. Disconnect every data and network cable from the secondary.
3. Disconnect every HA heartbeat cable from the secondary. If heartbeat links remain connected while restoring the backup, all cluster members will reboot.
4. Establish both GUI and console access to the isolated secondary.
5. Restore the cluster-member backup. The GUI session will be lost when interface and management settings change, but console access remains available through the configured local super_admin.
6. Wait for the FortiGate to boot, then use the console to sign in with the local administrator from the first substep.
7. Set the secondary hostname and ensure its HA priority is lower than the primary:

config system global
    set hostname <secondary_unit>
end

config system ha
    set priority <lower than priority on primary unit>
end

8. If a reserved HA management interface is configured, assign the secondary's dedicated address. Skip this if the cluster does not use a reserved management interface:

config system interface
    edit <mgmt-interface>
        set ip <dedicated secondary_unit ip> <subnet mask>
end

If the new unit's management interface must use a different subnet, also configure a gateway for the HA management interface under config system ha. These changes preserve the correct secondary hostname, out-of-band management where used, and secondary-member selection. 9. Reconnect the secondary's HA heartbeat cables. 10. On the primary, monitor HA state until the secondary appears and reports in sync:

get system ha status

11. Reconnect the secondary's data and network cables.

12. Compare ISDB versions.

An HA mismatch can occur when one member has one or more ISDB entries that do not exist on the other member because the ISDB database versions differ. Upgrade the ISDB database on the device with the older version so both FortiGate units use the same ISDB version. The cluster should synchronize after the update.

16. Check certificate bundle differences when vpn.certificate.ca is implicated.

Run:

diagnose autoupdate versions | grep Certificate -A6

Compare the Certificate Bundle information between members.

Run the following on the primary and confirm every member appears and reports in-sync:

get system ha status

Then compare checksums across the cluster:

diagnose sys ha checksum cluster

The global, affected VDOM, and aggregate all checksums should match on every member. The GUI at System -> HA should no longer show Not Synchronized or list out-of-sync objects.

No general rollback procedure is specified. Before isolating the secondary or restoring configuration, retain a valid backup created with a super_admin account. If HADiff logging was enabled, disable it and clear the log after troubleshooting:

diagnose sys ha hadiff log disable

diagnose sys ha hadiff log clear