Description
This article describes the behavior of FortiManager in managing FortiGate HA deployed in Public Cloud such as AWS or Azure with vdom-exception configured.
Scope
FortiManager v7.2.2.
Solution
FortiManager v7.2.2 has improved the features to manage FortiGate HA deployed in AWS/Azure with vdom-exception configured.
In FortiGate HA Public Cloud, the configuration included in vdom-exception will not synchronize between FortiGate HA.
Example.
'FGT A' Virtual IP’s:
'FGT B' Virtual IP’s:
HA Status:
As a result, FortiManager will have challenges managing the difference in configuration or Policy Package when FortiGate HA is experiencing a failover. In order to overcome this complexity, FortiManager v7.2.2 will read-only on the configuration included in vdom-exception.
The example below will provide more details on the behaviors.
Note:
FortiGate 1 VIP is named as a number, and FortiGate 2 VIP is named as the alphabet for comparison.
When FortiGate HA Public Cloud is added to FortiManager, FortiManager will retrieve and import configuration from the Primary FortiGate only.
Any changes made in Primary FortiGate will auto-update to the FortiManager database.
On the other hand, if vdom-exception configuration is made in Secondary FortiGate will not update to the FortiManager database.
In the FortiManager database, it will maintain as synchronized for both config status and policy package status:
After the failover, FortiManager will retrieve the latest configuration from the new Primary FortiGate. The status will change to Auto-Update:
However, it will not retrieve and import the configuration listed in vdom-exception. For this example: the FortiGate has failover but Virtual IP’s still remain as FortiGate 1:
Although there is a difference in the VIP, the next installation will not overwrite the configuration in the new FortiGate, and Install Preview will display empty:
In order to have the vdom-exception object of the new Primary FortiGate in FortiManager, the user needs to manually retrieve and import the configuration.
Note:
The device database will overwrite the vdom-exception object and replace it with the latest Primary FortiGate value.
However, in ADOM database (Policy Package) will contain all objects from both FortiGate:
Although all the objects are contained in the ADOM database, FortiManager will ignore all of these objects included in vdom-exception and will not install anything even object is modified. This precaution is implemented to prevent FortiManager install the objects from FortiGate 1 to FortiGate 2. However, if FortiGate 2 objects are added to FortiGate 1 firewall policy, FortiManager will prompt the user as data src invalid:
If the user likes to make changes to the object listed in vdom-exception, it needs to be configured from the Device database:
Note:
After changes are made in the device database and the object in vdom-exception is related to the firewall policy, the policy package status will become out of sync. In that case, the user must install it together with Policy Package to synchronize both the device database and ADOM database.
In summary, vdom-exception is in read-only mode for the ADOM database only. The ADOM database only allowed objects in vdom-exception to be added into firewall policy provided that the Local FortiGate has the object created. Else, it will not create the object for the FortiGate, and installation unable to proceed. On the other hand, the device database is still able to make the changes and the user will need to be cautious on the installation.
Related document:
https://docs.fortinet.com/document/fortigate/7.4.0/administration-guide/105611/vdom-exceptions
