Special Notices

This section highlights some of the operational changes that administrators should be aware of in 7.6.0.

FortiManager instances deployed on the Azure platform

FortiManager instances deployed on the Azure platform (regardless of version) may lose all data—including configuration, logs, and reports—if the VM is deallocated and subsequently reallocated.

This issue can occur when the VM is deallocated through Azure-level operations (e.g., Azure portal, CLI, or automation). For example, this may happen when an Azure administrator changes the VM SKU (e.g., from Standard_D16_v3 to Standard_D32a_v4), or when the VM is manually stopped (deallocated) from the Azure portal.

To minimize the risk of data loss, it is strongly recommended to:

• Perform regular backups of configuration and data via the GUI or native CLI commands on FortiManager.

• Shut down the FortiManager instance, if required, only from within the FortiManager system itself rather than through Azure-level controls.

• Before performing any upgrade or modification:

Run execute lvm info to verify disk composition and ensure no Azure temporary disk is included in LVM, For example:

Disk 1: 10 TB, Disk 2: 6 TB, ...

If all listed disks were explicitly added by the fmg-admin, this indicates that no temporary disk is part of LVM and the upgrade is considered safe.

If an unexpected disk is detected (e.g., smaller system disk such as ~128 GB), it is likely the Azure temporary disk. In this case, perform a full backup before proceeding with the upgrade.

If issues occur after the upgrade:

• Run execute format disk to rebuild LVM,

• Use execute restore to recover data from backup.

The possible root cause may be as follows:

Prior to version 7.4.2, the system assumed sdb was always the Azure temporary disk and excluded it from LVM. In certain corner cases, a different device (e.g., sda) may have been incorrectly added to LVM. After upgrading, the existing LVM metadata persists on disk. When the VM is later deallocated and reallocated, Azure replaces the temporary disk, causing LVM initialization to fail due to stale metadata. As a result, any data previously stored on the temporary disk is lost.

FortiManager and FortiClient EMS compatibility

In FortiClient EMS 7.4.5, the communication protocol has been upgraded from HTTP/1.0 to HTTP/2. Unlike HTTP/1.x, HTTP/2 does not return a traditional "200 OK" text response, so previous versions of FortiManager that expect this format cannot interpret the new HTTP/2 replies. Because of this, versions prior to FortiManager 7.4.9 and 7.6.5 are not compatible with the EMS version 7.4.5 and later.

FortiAP support in 7.2 and 7.4 ADOMs

In FortiOS 7.4.4, the available radio band format options used in FortiAP configurations has changed. This updated syntax is reflected in FortiManager 7.4.3/7.6.0 and later in version 7.4 ADOMs. As a result of this syntax difference, FortiManager 7.4.3/7.6.0 and later does not support installing FortiAP profile configurations from a 7.4 ADOM to a 7.2 FortiAP device (downgrade installation), or configurations from a 7.2 ADOM on a 7.4 FortiAP device (upgrade installation).

FortiSASE is currently not compatible on FortiManager 7.6

The latest release of FortiSASE is not compatible with FortiManager 7.6. Compatibility is available for FortiManager 7.4. For more information, see the FortiSASE Release Notes.

Log insertion interruption when upgrading from 7.40/7.4.1 to 7.6.0

Log insertion might be interrupted if FortiManager is upgraded directly from version 7.4.0/7.4.1 to 7.6.0. This issue only occurs if FortiAnalyzer Features are enabled on the FortiManager.

To avoid this issue, upgrade to a later FortiManager 7.4 version (for example, 7.4.2 or 7.4.3) before upgrading to 7.6.0. As a general best practice, Fortinet recommends upgrading to the latest patch version available before upgrading to the next major version.

Shell access has been removed

As of FortiManager 7.6.0, shell access has been removed.

The following CLI variables have been removed, which were previously used to enable shell access:

config system admin setting

set shell-access {enable | disable}

set shell-password <passwd>

The following CLI command has been removed, which was previously used to access shell when enabled:

execute shell

Enable fcp-cfg-service for Backup Mode ADOMs

When performing a configuration backup from the CLI of FortiGates managed by FortiManager in Backup Mode ADOMs, you must enable the "fcp-cfg-service" using the following command on the FortiManager:

config system global

set fcp-cfg-service enable

end

FortiSOAR MEA license must be activated or uploaded

In previous versions, the trial license was automatically activated when the FortiSOAR MEA was enabled. Beginning in FortiManager 7.6.0, which includes the FortiSOAR MEA 7.6.0, you must activate the trial license or upload a license to use the FortiSOAR MEA.

After enabling the FortiSOAR MEA, go to Management Extensions > FortiSOAR to activate or upload the license. For more information, see the Management Extensions documentation in the FortiManager Document Library.

ADOM upgrade for FortiManager 7.6

Currently, there is no ADOM upgrade option for ADOM version 7.4 to move to version 7.6. In order to manage FortiGates running 7.6, please add the devices to a 7.6 ADOM.

System Templates include new fields

Beginning in FortiManager 7.4.3, the Hostname, Timezone, gui-device-latitude, and gui-device-longitude fields have been added to System Templates.

System Templates created before upgrading to 7.4.3 must be reconfigured to specify these fields following the upgrade. If these fields are not specified in a System Template, the default settings will be applied the next time an install is performed which may result in preferred settings being overwritten on the managed device.

Custom certificate name verification for FortiGate connection

FortiManager 7.4.3 introduces a new verification of the CN or SAN of a custom certificate uploaded by the FortiGate admin. This custom certificate is used when a FortiGate device connects to a FortiManager unit. The FortiGate and FortiManager administrators may configure the use of a custom certificate with the following CLI commands:

FortiGate-related CLI:

config system central-management

local-cert Certificate to be used by FGFM protocol.

ca-cert CA certificate to be used by FGFM protocol.

FortiManager-related CLI:

config system global

fgfm-ca-cert set the extra fgfm CA certificates.

fgfm-cert-exclusive set if the local or CA certificates should be used exclusively.

fgfm-local-cert set the fgfm local certificate.

Upon upgrading to FortiManager 7.4.3, FortiManager will request that the FortiGate certificate must contain the FortiGate serial number either in the CN or SAN. The tunnel connection may fail if a matching serial number is not found. If the tunnel connection fails, the administrator may need to re-generate the custom certificates to include serial number.

Alternatively, FortiManager 7.4.3 provides a new CLI command to disable this verification. Fortinet recommends to keep the verification enabled.

config system global

fgfm-peercert-withoutsn set if the subject CN or SAN of peer's SSL certificate sent in FGFM should include the serial number of the device.

When the CLI setting fgfm-peercert-withoutsn is disabled (default), the FortiGate device's certificate must include the FortiGate serial number in the subject CN or SAN. When the CLI setting fgfm-peercert-withoutsn is enabled, the FortiManager unit does not perform the verification serial number in subject CN or SAN.

Additional configuration required for SSO users

Beginning in 7.4.3, additional configuration is needed for FortiManager Users declared as wildcard SSO users.

When configuring Administrators as wildcard SSO users, the ext-auth-accprofile-override and/or ext-auth-adom-override features, under Advanced Options, should be enabled if the intent is to obtain the ADOMs list and/or permission profile from the SAML IdP.

When using VPN Manager, IPSEC VPN CA certificates must be re-issued to all devices after upgrade

When FortiManager is upgraded to 7.4.2/7.6.0 or later, it creates a new CA <ADOM Name>_CA3 certificate as part of a fix for resolved issue 796858. See Resolved Issues in the FortiManager 7.4.2 Release Notes. These certificates are installed to the FortiGate devices on the next policy push. As a result, the next time any IPSEC VPNs which use FortiManager certificates rekey, they will fail authentication and be unable to re-establish.

The old CA <ADOM Name>_CA2 cannot be deleted, as existing certificates rely on it for validation. Similarly, the new CA <ADOM Name>_CA3 cannot be deleted as it is required for the fix. Therefore, customers affected by this change must follow the below workaround after upgrading FortiManager to v7.4.2/7.6.0 or later.

A maintenance period is advised to avoid IPSEC VPN service disruption.

Workaround:

Re-issue all certificates again to all devices, and then delete the old CA <ADOM Name>_CA2 from all devices. Next, regenerate the VPN certificates.

To remove CA2 from FortiManager, Policy & Objects > Advanced > CA Certificates must be enabled in feature visibility.

FortiGuard web filtering category v10 update

Fortinet has updated its web filtering categories to v10, which includes two new URL categories for AI chat and cryptocurrency web sites. In order to use the new categories, customers must upgrade their Fortinet products to one of the versions below.

• FortiManager - Fixed in 6.0.12, 6.2.9, 6.4.7, 7.0.2, 7.2.0, 7.4.0.

• FortiOS - Fixed in 7.2.8 and 7.4.1.

• FortiClient - Fixed in Windows 7.2.3, macOS 7.2.3, Linux 7.2.3.

• FortiClient EMS - Fixed in 7.2.1.

• FortiMail - Fixed in 7.0.7, 7.2.5, 7.4.1.

• FortiProxy - Fixed in 7.4.1.

Please read the following CSB for more information to caveats on the usage in FortiManager and FortiOS.

https://support.fortinet.com/Information/Bulletin.aspx

FortiManager 7.2.3 and later firmware on FortiGuard

Starting in FortiManager 7.2.1, a setup wizard executes to prompt the user for various configuration steps and registration with FortiCare. During the execution, the FortiManager unit attempts to communicate with FortiGuard for a list of FortiManager firmware images currently available on FortiGuard – older and newer.

In the case of FortiManager 7.2.2, a bug in the GUI prevents the wizard from completing and prevents the user from accessing the FortiManager unit. The issue has been fixed in 7.2.3 and later and a CLI command has been added to bypass the setup wizard at login time.

config system admin setting

set firmware-upgrade-check disable

end

Fortinet has not uploaded FortiManager 7.2.3 and later firmware to FortiGuard in order to work around the GUI bug, however, the firmware is available for download from the Fortinet Support website.

Configuration backup requires a password

As of FortiManager 7.4.2, configuration backup files are automatically encrypted and require you to set a password. The password is required for scheduled backups as well.

In previous versions, the encryption and password were optional.

For more information, see the FortiManager Administration Guide.

FortiManager-400E support

FortiManager 7.4.2 and later does not support the FortiManager-400E device.

FortiManager 7.4.2 introduces an upgrade of the OpenSSL library to address known vulnerabilities in the library. As a result, the SSL connection that is setup between the FortiManager-400E device and the Google Map server hosted by Fortinet uses a SHA2 (2048) public key length. The certificate stored on the BIOS that is used during the setup of the SSL connection contains a SHA1 public key length, which causes the connection setup to fail. Running the following command shows the key length.

FMG400E # conf sys certificate local

(local)# ed Fortinet_Local

(Fortinet_Local)# get

name : Fortinet_Local

password : *

comment : Default local certificate

private-key :

certificate :

Subject: C = US, ST = California, L = Sunnyvale, O = Fortinet, OU = FortiManager, CN = FL3K5E3M15000074, emailAddress = support@fortinet.com

Issuer: C = US, ST = California, L = Sunnyvale, O = Fortinet, OU = Certificate Authority, CN = support, emailAddress = support@fortinet.com

Valid from: 2015-03-06 16:22:10 GMT

Valid to: 2038-01-19 03:14:07 GMT

Fingerprint: FC:D0:0C:8D:DC:57:B6:16:58:DF:90:22:77:6F:2C:1B

Public key: rsaEncryption (1024 bits)

Signature: sha1WithRSAEncryption

Root CA: No

Version: 3

Serial Num:

1e:07:7a

Extension 1: X509v3 Basic Constraints:

CA:FALSE

...

(Fortinet_Local)#

Serial console has changed for FortiManager deployments on Xen

As of FortiManager 7.4.1, the serial console for Xen deployments has changed from hvc0 (Xen specific) to ttyS0 (standard).

OpenXen in PV mode is not supported in FortiManager 7.4.1

As of FortiManager 7.4.1, kernel and rootfs are encrypted. OpenXen in PV mode tries to unzip the kernel and rootfs, but it will fail. Therefore, OpenXen in PV mode cannot be used when deploying or upgrading to FortiManager 7.4.1. Only HVM (hardware virtual machine) mode is supported for OpenXen in FortiManager 7.4.1.

Option to enable permission check when copying policies

As of 7.4.0, a new command is added in the CLI:

config system global

set no-copy-permission-check {enable | disable}

end

By default, this is set to disable. When set to enable, a check is performed when copying policies to prevent changing global device objects if the user does not have permission.

Install On column for policies

Prior to version 7.2.3, the 'Install-on' column for policies in the policy block had no effect. However, starting from version 7.2.3, the 'Install-on' column is operational and significantly impacts the behavior and installation process of policies. It's important to note that using 'Install-on' on policies in the policy block is not recommended. If required, this setting can only be configured through a script or JSON APIs.

Changes to FortiManager meta fields

Beginning in 7.2.0, FortiManager supports policy object metadata variables.

When upgrading from FortiManager 7.0 to 7.2.0 and later, FortiManager will automatically create ADOM-level metadata variable policy objects for meta fields previously configured in System Settings that have per-device mapping configurations detected. Objects using the meta field, for example CLI templates, are automatically updated to use the new metadata variable policy objects.

Meta fields in System Settings can continue to be used as comments/tags for configurations.

For more information, see ADOM-level meta variables for general use in scripts, templates, and model devices.

View Mode is disabled in policies when policy blocks are used

When policy blocks are added to a policy package, the View Mode option is no longer available, and policies in the table cannot be arranged by Interface Pair View. This occurs because policy blocks typically contain policies with multiple interfaces, however, View Mode is still disabled even when policy blocks respect the interface pair.

Reconfiguring Virtual Wire Pairs (VWP)

A conflict can occur between the ADOM database and device database when a Virtual Wire Pair (VWP) is installed on a managed FortiGate that already has a configured VWP in the device database. This can happen when an existing VWP has been reconfigured or replaced.

Before installing the VWP, you must first remove the old VWP from the device's database, otherwise a policy and object validation error may occur during installation. You can remove the VWP from the device database by going to Device Manager > Device & Groups, selecting the managed device, and removing the VWP from System > Interface.

Citrix XenServer default limits and upgrade

Citrix XenServer limits ramdisk to 128M by default. However the FMG-VM64-XEN image is larger than 128M. Before updating to FortiManager 6.4, increase the size of the ramdisk setting on Citrix XenServer.

To increase the size of the ramdisk setting:

1. On Citrix XenServer, run the following command:

   xenstore-write /mh/limits/pv-ramdisk-max-size 536,870,912

2. Confirm the setting is in effect by running xenstore-ls.

   -----------------------

   limits = ""

   pv-kernel-max-size = "33554432"

   pv-ramdisk-max-size = "536,870,912"

   boot-time = ""

   ---------------------------

3. Remove the pending files left in /run/xen/pygrub.

The ramdisk setting returns to the default value after rebooting.

Multi-step firmware upgrades

Prior to using the FortiManager to push a multi-step firmware upgrade, confirm the upgrade path matches the path outlined on our support site. To confirm the path, please run:

dia fwmanager show-dev-upgrade-path <device name> <target firmware>

Alternatively, you can push one firmware step at a time.

Hyper-V FortiManager-VM running on an AMD CPU

A Hyper-V FMG-VM running on a PC with an AMD CPU may experience a kernel panic. Fortinet recommends running VMs on an Intel-based PC.