HA Secondary Changed Out of Band
Northwind has a FortiGate 600E active-passive HA pair managed by FortiManager 7.4.3 in ADOM 7.4. The cluster is represented by one managed device, HQ-FW. FortiManager installs a revised policy package to HQ-FW. The primary reports a successful install and HA status remains Primary. Two hours later, the secondary shows Configuration Status Out of Sync in FortiManager, and diagnose sys ha checksum show differs between the units. The only recent change was made by a junior admin who logged into the secondary's out-of-band GUI and added a static route to 10.20.0.0/16 and changed config system ha priority. The junior admin cannot explain why the change did not appear on the primary. The security team wants to know whether FortiManager caused the mismatch and how to restore a trustworthy HA pair without importing the wrong config.
1. Did FortiManager cause the mismatch? Explain the HA and FortiManager behavior that produced the symptom.
Read the worked answer
FortiManager did not create the mismatch. In an active-passive cluster, configuration is synchronized one way from primary to secondary; a change made on the secondary is not pushed back to the primary. FMG installs to the cluster through the primary, so the static route and HA priority change on the secondary stayed local. FMG's Configuration Status is based on its last install and revision view and is not a live HA checksum monitor, so it can show Out of Sync after an out-of-band change. Do not fix this by retrieving configuration from the secondary into FMG; that would import the rogue route into the central database and potentially push it to the primary. Treat the primary as the only authoritative source and verify HA checksums on both units before making changes.
2. Give ordered remediation steps to restore synchronization without importing the wrong configuration.
Read the worked answer
- On both units, run diagnose sys ha checksum show and compare sections to confirm the mismatch. 2) On the secondary, run execute ha synchronize start, or reboot the secondary if synchronization does not complete. 3) Recheck checksums and HA status; the secondary should match the primary. 4) Decide whether the static route is required. If yes, add it on the primary or in the FMG device database and install from FMG; if no, leave it removed by the synchronization. 5) From FMG, retrieve or compare the primary config only if the central database is suspected stale, then install and verify. Never install separately to the secondary and never add both HA members as independent FMG devices, because that creates competing device databases.
3. What preventive controls would stop this from recurring while keeping break-glass access?
Read the worked answer
Restrict GUI and SSH access on the secondary to a break-glass account with trusted hosts, or disable direct administrative access in normal operation and manage through FMG and the primary. Document that all HA configuration changes go to the primary. Monitor HA checksums and FMG configuration status, and alert on mismatch. For planned changes, confirm cluster health before and after install. Use HA override deliberately: if enabled, a rebooted secondary with higher priority can take over and confuse change control; if disabled, the primary stays primary. Finally, include HA checksum verification in the post-install checklist so an out-of-band change is caught before the next policy install.