| Description |
This article describes the behavior of the Per-VDOM Threat Feed Connector in The FortiGate HA virtual cluster with the VDOM partition configured. |
| Scope | FortiGate HA with VDOM partition. |
| Solution |
The per-VDOM Threat Feed Connector was introduced after FortiOS 7.0.0. With this feature, each VDOM can define its own Threat Feed Connector to import an external block list from an HTTP server. This list can be used in this VDOM only and won’t be shared by other VDOMs.
Only the primary unit will connect to the HTTP server to import the external block list for the FortiGate HA cluster setup. The secondary unit will update the list using HA synchronization.
There has been a scenario that in a HA virtual cluster with multiple VDOMs configured, some VDOM is acting as primary on a unit while some VDOM is the secondary.
In the below example, the device ‘c3po-kvm80’ and ‘c3po-kvm32’ form a HA cluster. The ‘root’ and ‘test1’ VDOMs are in the primary role in unit ‘c3po-kvm80’ while the ‘test’ VDOM is in the primary role in unit ‘c3po-kvm32’.
Both ‘test’ and ‘test1’ VDOM have Per-VDOM Threat Feed Connector configured.
In ‘test’ VDOM:
config system external-resource edit "test-domain" set uuid b59adba4-bd2b-51ef-128c-268f2b131bbb set category 193 set resource "http://10.56.245.134" set refresh-rate 1 next end
In ‘test1’ VDOM:
config system external-resource edit "test1_domain" set uuid afc086f4-bdd8-51ef-183d-bfd5eb32d769 set category 193 set resource "http://10.56.245.134" set refresh-rate 1 next end
However, by checking the Threat Feed Connector status on the primary, the ‘test’ VDOM couldn’t get the external block list updated from the HTTP server while the ‘test1’ VDOM can get the whole list updated.
‘test’ VDOM (primary unit is ‘c3po-kvm32’):
‘test1’ VDOM (primary unit is ‘c3po-kvm80’):
By checking the connectivity to the HTTP server, both VDOMs have connectivity on port 80 from the primary. ‘test’ VDOM:
‘test1’ VDOM:
The reason why the ‘test’ VDOM could not get the external block list updated from the HTTP server through the Threat Feed Connector is because the Connector only starts the download from the FortiGate where the management VDOM (root VDOM by default) is the master in the cluster. For the ‘test’ VDOM which is a separate Virtual Cluster, its primary is the ‘c3po-kvm32’ which, however, is the secondary for the root VDOM. In that case, the update request will not be initiated.
The workaround to get rid of this situation is to failover the primary of the ‘test’ VDOM to the device ‘c3po-kvm80’ which is the primary of the management VDOM. The way to failover a Virtual Cluster can be achieved by modifying the priority under the HA setting.
Once the failover is done, the ‘Threat Feed Connector’ starts getting the updated HTTP server on the primary device.
For the long-term solution, the development team has implemented adjustments starting from FortiOS versions 7.4.5 and 7.6.0. From these versions onward, the VDOM with the opposite HA role to the root (as in this case) can receive updates from the HTTP server via the Threat Feeds Connector without triggering a failover.
Related documents: |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2025 Fortinet, Inc. All Rights Reserved.