Troubleshooting an HA cluster that remains out of sync after a FortiOS upgrade

1. Back up the current configuration before troubleshooting. Be aware that changes made after HA synchronization failed may not exist on the peer, even when the cluster later appears synchronized.

2. On both FortiGate units, review configuration errors recorded during the upgrade:

diag debug config-error-log read

3. On the primary unit, check the crash log for evidence that the HA daemon is crashing:

diag debug crashlog read

4. Compare HA checksums by running the following command on both units and comparing the complete output:

diagnose sys ha checksum test

5. If the checksums match but HA remains out of sync, recalculate them on both units:

diagnose sys ha checksum recalculate

This can clear the displayed status, but it may only be temporary. Make a controlled policy change afterward and confirm that it reaches the peer.

6. If the problem continues, restart the HA synchronization processes on both firewalls at the same time:

fnsysctl killall hasync
fnsysctl killall hatalk

A reported FortiGate 61F cluster affected after upgrading from 7.2.8 to 7.2.9 synchronized after these commands were run concurrently on both members.

7. If synchronization still fails, collect HA debug output on both firewalls. Reset debugging, enable timestamps and debugging for hasync and hatalk, then restart synchronization:

diag debug reset
diag debug enable
execute ha synchronize stop
diag debug console timestamp enable
diag debug application hasync -1
diag debug application hatalk -1
execute ha synchronize start

When sufficient output has been captured, stop debugging:

diag debug reset
diag debug disable

8. Review the output for repeated timeouts, peer-closed connections, or aborted synchronization to 169.254.0.1. Reported messages included error 110(Connection timed out) and failures affecting sync_type=3(fib), sync_type=4(ipsec), sync_type=5(conf), sync_type=6(proxy), sync_type=14(diff), sync_type=18(byod), sync_type=24(mcast), and sync_type=27(capwap).

9. If restarting the HA processes alone does not recover synchronization, one reported workaround was to restart those processes on both units and then reboot both firewalls. To access an HA member and reboot it, use:

execute ha manage 0 <username>
execute reboot

Plan this step for an approved maintenance window because rebooting both members can affect traffic.

10. If execute update-now fails on the secondary with code -6, isolated Internet access may allow the update to complete:

execute update-now

In the reported case, completing the update did not correct HA synchronization, so this is diagnostic context rather than a confirmed fix.

11. If the cluster remains out of sync, if synchronization fails again after a configuration change, or if the HA daemons crash, open a Fortinet TAC case. Include checksum output, configuration error logs, crash logs, and hasync/hatalk debug output. Do not repeatedly factory-reset a remote secondary without TAC guidance and an appropriate recovery plan.

Confirm that the HA status reports the cluster as synchronized. Do not rely only on the displayed status: make a controlled policy change and verify that the change is present on the peer and that HA remains synchronized. Run diagnose sys ha checksum test on both members and compare the results. Continue monitoring for recurring hasync or hatalk errors and retain a configuration backup before any further upgrade.

No specific FortiOS rollback procedure was provided. Restore from a known-good configuration backup if required, particularly if changes made during the failed synchronization period were lost. Escalate to Fortinet TAC before attempting firmware rollback or additional factory resets.