We encountered an interesting — and quite disruptive — behavior in a High Availability (HA) setup.
Situation Overview
When restoring a configuration on one cluster node, the entire configuration of the other nodes was overwritten — including settings that are supposed to remain unique and unsynced, such as hostnames, management IP addresses, and other node-specific parameters.
In plain terms:
The one cluster member pushes the entire restore configuration onto other cluster members.
Automation Stitch
We discovered the issue by restoring the configuration through Automation Stitch. In our lab environment, Stitch is configured to automatically revert the configuration on a daily basis by pulling the latest baseline config from an FTP share and applying it to the primary node.
This approach makes sense in a controlled lab scenario — frequent config resets ensure that test systems return to a known, stable state each day, maintaining consistency across test runs and preventing configuration drift.
However, during one of these routine daily restores, the HA cluster broke immediately. The secondary nodes were overwritten, losing their hostnames and other node-specific configurations: The cluster was no longer operational.
Manual Restore – Same Behavior
To eliminate the possibility that Stitch or the FTP process introduced the issue, we performed a manual restore of the configuration directly on the node.
- Result: Identical outcome.
- All cluster member were again overwritten, and the cluster became unusable.
This confirmed that the root cause is not automation-related. Whether the configuration is uploaded manually or through automation tools (like Stitch pulling from FTP), the end result is the same — the restore process on the one overwrites the entire HA topology configuration, including specific details.
Root Cause & Internal Tracking
After internal investigation with Fortinet, the vendor confirmed that this exact behavior is already known and documented under a internal engineering ticket.
Fix & Release Plan
A fix for this issue is scheduled for the FortiOS version 7.6.5, planned for release in early to mid next month.
Until that version becomes available, the recommended best practice is:
- Do not perform configuration restores while the HA cluster is active.
- If a restore is required, disconnect the HA cluster first, and then perform the restore.
This applies both to manual restores and to automated restores (e.g., via Stitch).
Stay secure!
