The GUI is showing the HA status as 'Unknown':
 The possible causes of this are as follows:
The Secondary FortiGate is running a different firmware version:Â Â Run the following commands on both firewalls to confirm the firmware version:
get system status Â
Refer to this article for accessing the secondary unit in the cluster:Â Technical Tip: How to access secondary unit of HA cluster via CLI.
The primary is on v7.4.7 as follows:
cgw-pri-XXXXX-gatech # get system status
Version: FortiGate-61F v7.4.7,build2731,250120 (GA.M) <-----
First GA patch build date: 230509
Security Level: High
Firmware Signature: certified
 The secondary is on v7.4.5 as follows:
cgw-sec-XXXX-gatech # get system status
Version: FortiGate-61F v7.4.5,build2702,240916 (GA.M) <-----
First GA patch build date: 230509
Security Level: 2
Firmware Signature: certified
If the split-brain is present: See Technical Tip: High Availability - Split Brain. If ha and mgmt interface are used as hbdev ports: See Technical Tip: HA out-of-sync and 'No route to host' error when accessing secondary device from CLI. If it is required to revert the HA cluster to the previous firmware: See Technical Tip: How to revert HA cluster unit to the previous firmware image. If the output of 'di sys ha checksum cluster' only shows the checksum on one device, but 'get system ha status' shows the two units: restart/kill the HASYNC daemon on the Primary Device in the Cluster.
fnsysctl killall hasyncÂ
If the output of 'diagnose system ha checksum cluster' displays a checksum for only one device, while 'get system ha status' shows the checksum for the secondary device as '00 00 00 00 00 00 00' this indicates that the secondary device is not reporting a valid HA checksum.
FGT~-01 (global) # diagnose sys ha checksum cluster
================== FG181FTK2XXXXXXXX ==================
is_manage_primary()=0, is_root_primary()=0
debugzone
global: 83 9a 51 5a c1 81 9d b1 49 21 78 6c 95 be 6d 68
root: 76 be fb b9 8b b6 c6 ff 46 55 d8 14 4f 00 64 0c
XXXX: d7 49 ac 17 92 94 a0 af 1b 85 b7 4f b0 b1 bf 21
YYYY: b3 0e f3 0b 6a d1 52 b4 63 72 c6 06 ae d7 d1 c9
all: 98 a0 a8 bf d2 7a 32 7a 8a 9c 85 e2 01 5a d2 7b
checksum
global: 83 9a 51 5a c1 81 9d b1 49 21 78 6c 95 be 6d 68
root: 76 be fb b9 8b b6 c6 ff 46 55 d8 14 4f 00 64 0c
XXXX: d7 49 ac 17 92 94 a0 af 1b 85 b7 4f b0 b1 bf 21
YYYY: b3 0e f3 0b 6a d1 52 b4 63 72 c6 06 ae d7 d1 c9
all: 98 a0 a8 bf d2 7a 32 7a 8a 9c 85 e2 01 5a d2 7b
================== FG181FTK2XXXXXXXX ==================
//checksum is empty
FGT (global) # get system ha status
HA Health Status: OK
Model: FortiGate-1801F
Mode: HA A-P
Group Name: HA
Group ID: 25
Debug: 0
Cluster Uptime: 715 days 4:25:58
Cluster state change time: 2025-03-11 14:09:58
Primary selected using:
<2026/08/08 14:09:58> vcluster-1: FG181FTK2XXXXXXXX is selected as the primary because its uptime is larger than peer member FG181FTK2XXXXXXXX.
<2026/08/08 02:57:40> vcluster-1: FG181FTK2XXXXXXXX is selected as the primary because its override priority is larger than peer memb
er FG181FTK2XXXXXXXX.
ses_pickup: enable, ses_pickup_delay=disable
override: disable
Configuration Status:
FG181FTK2XXXXXXXX(updated 5 seconds ago): in-sync
FG181FTK2XXXXXXXX chksum dump: ac 67 d5 85 6a 38 8b 73 59 34 a7 d6 55 45 f9 52
FG181FTK2XXXXXXXX(updated 1741773331 seconds ago): out-of-sync
FG181FTK2XXXXXXXX chksum dump: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <===========
The following error is observed when running the following debug commands while attempting to connect to the secondary device from the primary device:
diagnose debug application hatalk -1
diagnose debug application hasync -1
diagnose debug enable
<hasync:WARN> conn=0x10969010 abort: rt=-2, dst=169.254.0.1, sync_type=5(conf)
[__ha_send_req_ex:1482] pid-7688 ha req connect failed: type=43, dst_ip=169.254.0.1, error=110(Connection timed out)
Restart/kill the HATALK daemon on the Primary Device in the Cluster.
fnsysctl killall hatalk
execute ha synchronize stop
execute ha synchronize start
diagnose system ha checksum recalculate
Note: Killing the 'hatalk' process should be performed during a maintenance window, as it may temporarily disrupt HA communication. |