FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
GeorgeZhong
Staff
Staff
Article Id 365547
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’.

 

GeorgeZhong_0-1734595041855.png

 

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’):

 

GeorgeZhong_1-1734595041861.png

 

‘test1’ VDOM (primary unit is ‘c3po-kvm80’):

 

GeorgeZhong_2-1734595041867.png

 

By checking the connectivity to the HTTP server, both VDOMs have connectivity on port 80 from the primary.

‘test’ VDOM:

 

GeorgeZhong_3-1734595041867.png

 

‘test1’ VDOM:

 

GeorgeZhong_4-1734595041868.png

 

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.

 

GeorgeZhong_5-1734595041874.png

 

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:

HA virtual cluster setup

Threat feeds

Threat feed connectors per VDOM

Technical Tip: Secondary's external files are not in sync with the primary's device in the HA cluste...