How FortiGate VDOM exceptions interact with FortiManager

In a typical FortiGate HA configuration, when a setting on the Primary FortiGate changes, those changes are automatically synchronized to the Secondary device.

In order to manually prevent certain settings from synchronizing between the Primary and Secondary devices in the HA cluster, administrators can configure VDOM exceptions. When a FortiGate's configuration is updated during failover, settings specified as VDOM exceptions are not changed. FortiManager administrators can still make changes to VDOM exception objects directly through the device database on FortiManager.

FortiManager treats VDOM exceptions as read-only in the ADOM database. When FortiManager adds the HA cluster, VDOM exception objects will only be added to firewall policies if the FortiGate has the object created locally, otherwise the object is not created.

VDOM exceptions can be required when FortiGate HA cluster members are not in the same physical location, subnets, or availability zones in a cloud environment. For example, you need to prevent management interfaces that have unique VIPs from being synchronized between cluster devices.

See the FortiGate Administration Guide for a list of settings and resources that can be exempted from synchronization in an HA cluster.

Example: VDOM exception for VIP objects

In the following example, an administrator wants to centrally manage a FortiGate Active-Passive HA cluster (FortiGate-A and FortiGate-B) with unique VIP objects hosted on AWS using FortiManager.

VDOM exception example:

1. FortiGate-A and FortiGate-B are each configured with unique VIP objects.

2. The administrator configures a VDOM exception for the VIP objects on FortiGate-A.
   

   For example, the administrator sets the following command:

   config vdom exception

   edit 1

   set object firewall.vip

   The VDOM exception only needs to be configured on the device that will be Primary in the cluster. The Secondary device will automatically synchronize the VDOM exception settings when the HA cluster is formed.

3. The administrator forms an HA cluster where FortiGate-A is the Primary and FortiGate-B is the Secondary.

   • VIP objects configured on the FortiGate devices are not synchronized between the Primary and Secondary because of the VDOM exception.

   • See the FortiGate/FortiOS Administrator Guide for more information on forming HA clusters.

4. The FortiGate cluster is added to FortiManager for central management.

   • FortiManager retrieves the configuration of the FortiGate cluster, and the cluster is displayed as Synchronized.
     

   • The VDOM exception objects (VIP objects in this example) are not synchronized between the cluster devices. FortiManager imports the configuration from the current Primary (FortiGate-A).

   • See Adding a model FortiGate HA cluster for more information on adding an FortiGate HA cluster to FortiManager.

5. After failover occurs, FortiGate-B becomes the new Primary, and FortiManager retrieves its configuration with auto-update.

   • FortiGate-B's VIP objects are not synchronized to the FortiManager databases and remain as local objects on the FortiGate.

   • In order to push any configuration changes to the new Primary (FortiGate-B), the administrator must first manually import its configuration. The VIP object from FortiGate-B will be updated in the device database, and the ADOM database will contain the VIP objects from FortiGate-A and FortiGate-B.

Additional Resources

• FortiOS AWS Administration Guide
• FortiOS Azure/Azure Stack Administration Guide
• FortiGate Administration Guide
• FortiGate CLI Reference