FortiManager overwrites settings on HA unicast heartbeat interface

Question

I have an HA cluster of two FortiGates (v6.0.9) managed by a FortiManager (v6.0.8).

The FortiGates run in a cloud, so I must use unicast heartbeat on HA interfaces to sync them. I use port10 on both FortiGates as such interface: [style="background-color: #c0c0c0;"]FortiGate01, port10, IP 192.168.219.251 <================> IP 192.168.219.252, port10, FortiGate02[/style]

The problem is: apparently, FortiManager doesn't understand what "Unicast HA heartbeat interface" is.

Let's say, FortiGate01 is now the Master. FortiManager remembers that the address on port10 is [style="background-color: #c0c0c0;"]192.168.219.251[/style]. Now, if a failover occurs and FortiGate02 becomes Master, then on next policy push from FortiManager its port10 IP address will be overwritten by [style="background-color: #c0c0c0;"]192.168.219.251[/style]. Which will in fact kill the cluster. Is there a way to instruct FortiManager to treat this interface differently? Maybe make it completely ignore this port10?

Vladimir_Ostrovsky · Answer

Response from Fortinet support: either disable validation on FortiManager ("[link=https://docs2.fortinet.com/document/fortimanager/6.0.8/cli-reference/784395/dm]set verify-install disable[/link]") or upgrade to FortiManager v6.2.3, which doesn't have this problem (according to them, I didn't verify that).

More details:

Yes, the install verification is disabled by "set verify-install disable" under "config system dm". It's more inconvenient than dangerous, because if the automatic verification is disabled, you would need to manually check the post install log (even if install=OK), to make sure that there were no errors returned by the target FortiGate. Generally if no errors in the install log the change is pushed correctly, but to stay on the safe side, you may also check in the FortiGate config, to confirm. Another option is to use "set verify-install optimal", which triggers automatic install verification only if an error is returned by the FortiGate. However, if the verification is triggered by an error, it may again change the HB IPs and break the cluster. Another strategy can be to leave the "dm" config as it is, and manually retrieve config revision (just retrieve, no import needed) after FortiGate HA failover. But this is also risky, because a failover can happen in any moment, may remain unnoticed by the FortiManager administrator, and ultimately cause the same problem. So unfortunately none of workarounds for FortiManager 6.0.8 is perfect.

Sign up

Login with SSO

Login to the community

Login with SSO