Some GUI pages may randomly take longer to load than expected or not load at all.

Management interfaces on the secondary FIM in a FortiGate-7000F cannot be used for the FGSP heartbeat.

Policy statistics data that appear on the GUI firewall policy pages and in FortiView may be incorrect.

After successfully resetting a managed FortiSwitich from the FortiGate-6000 or 7000 GUI, a Failed to factory reset FortiSwitich message may appear.

In some cases, the GUI will not display the Configuration Sync Monitor GUI page. You can work around this issue by stopping the node.js process. Once the node.js process is stopped, you will loose access to the GUI for a few seconds. Once node.js restarts you can access the GUI and the Configuration Sync Monitor GUI page should be available.

You can use the following command to find the node.js process number:

diagnose sys process pidof node

The output of this command will be the node.js process number. Enter the following command to stop the node.js process.

diagnose sys kill 9 <node.js-process-number>

The checksum of the root VDOM is missing from some parts of the output of the diagnose sys confsync showcsum command.

In some IPsec configurations that include dynamic routing , the IP address of an IPsec interface can be set to 0.0.0.0. This happens if the IP address for the interface is received before the interface is up, so the interface address is not configured.

You can work around this problem by flushing the tunnel using the IPsec interface that is not set up correctly.

FortiGate-6000 and 7000 do not support adding an EMAC VLAN interface to a VLAN interface. You can add an EMAC VLAN interface to a VLAN interface, but this could result in duplicate MAC addresses and duplicate HA virtual MAC addresses.

In some rare cases, an FPC or FPM may assign one or more FortiGate-6000 or FortiGate-7000 FIM network interfaces the HA virtual mac address 00:00:00:00:00:00.

You can use the diagnose hardware deviceinfo nic command to find the Current_HWaddr address assigned to each interface by each FPC or FPM.

You can work around this issue by running the diagnose sys ha mac command from the FortiGate-6000 management board CLI or FortiGate-7000 primary FIM CLI to recalculate HA virtual MAC addresses for all interfaces for all FPCs or FPMs. This command has been temporarily added for this release to help with this issue.

If the FortiGate-6000 or 70000 restarts or if you change the interface configuration (for example by changing the split interface configuration), the problematic HA virtual MAC address may revert to 00:00:00:00:00:00 and you will have to run the diagnose sys ha mac command again.

The Session Rate dashboard widget may not load or may be showing session rate data.

From the Global GUI, the System > VDOM page does not display any information and a Failed to load data message may also appear.

You can work around this issue by configuring VDOM properties from the CLI using the config system vdom-property command.

You can view the list of VDOMs from the CLI using the following command:

config vdom

edit ?

You can add a new VDOM from the CLI using the following command:

config vdom

edit <vdom-name>

You can delete a VDOM from the CLI using the following command:

config vdom

delete <vdom-name>

After upgrading from FortiOS 7.0.10 to 7.0.12, the FPCs or the secondary FIM and the FPMs will appear to be running un-certified firmware. This also applies to the FPCs or the secondary FIM and the FPMs in the secondary chassis in an HA configuration.

This problem occurs because of the way FortiOS 7.0.10 synchronized signatures from the management board to the FPCs or from the primary FIM to the secondary FIM and the FPMs during the firmware upgrade process.

FortiOS 7.0.12 fixes signature handling, so you can resolve this problem by installing FortiOS 7.0.12 firmware a second time, using a normal firmware upgrade procedure.

During a FortiGate-7000F firmware upgrade FPM CLI consoles may display messages similar to the following:

[ha_shm_mutex_enter:2781] fgtAttachShm() failed.

[update_ha_mac:3497] ha_shm_mutex_enter() failed.

These messages are caused by timing issues as the FPMs are starting up. Once the FPMs have started they should operate normally.

The iked process running on the FortiGate-6000 management board can randomly crash, blocking IPsec traffic. You can work around this issue by manually clearing current IPsec sessions after a crash occurs. IPsec sessions will then be restarted and will run normally. IPsec traffic will be blocked again if the iked process crashes again and you can repeat the workaround to restart IPsec sessions.

From the FortiGate-6000 management board GUI, the Security Rating page may incorrectly flag firewall policies as Unused Policies, even though these policies have been processing traffic.This is happening because the management board Security Rating system is not receiving policy usage information from the FPCs. If you log into an FPC GUI, you can verify that the Security Rating page has not flagged the same policies as as unused policies.

Graceful upgrade of a FortiGate 6000 or 7000 FGCP HA cluster is not supported when upgrading from FortiOS 7.0.12 to 7.2.5.

Upgrading the firmware of a FortiGate-6000 or 7000 FGCP HA cluster from 7.0.12 to 7.2.5 should be done during a maintenance window, since the firmware upgrade process will disrupt traffic for a few minutes.

Before upgrading the firmware, disable uninterruptible-upgrade. Then perform a normal firmware upgrade. During the upgrade process the FortiGates in the cluster will not allow traffic until all components (management board and FPCs or FIMs and FPMs) are upgraded and both FortiGates have restarted. This process can take a few minutes.

SLBC for FortiOS 7.0 and 7.2 uses different FGCP HA heartbeat formats. Because of the different heartbeat formats, you can't create an FGCP HA cluster of two FortiGate 6000s or 7000s when one chassis is running FortiOS 7.0.x and the other is running FortiOS 7.2.x. Instead, to form an FGCP HA cluster, both chassis must be running FortiOS 7.0.x or 7.2.x.

If two chassis are running different patch releases of FortiOS 7.0 or 7.2 (for example, one chassis is running 7.2.5 and the other 7.2.6), they can form a cluster. When the cluster is formed, FGCP elects one chassis to be the primary chassis. The primary chassis syncs its firmware to the secondary chassis. As a result, both chassis will be running the same firmware version.

You could also form a cluster if one chassis is running FortiOS 7.2.x and the other is running 7.4.x.

For best results, both chassis should be running the same firmware version, although as described above, this is not a requirement.