FortiGate VDOM Policy Management: Best Practices for Multi-Tenant Environments

fortigate vdom policy management in detail — a critical topic for network security engineers managing enterprise FortiGate environments.

If you’ve ever inherited a FortiGate environment with more than a handful of VDOMs, you know that the complexity doesn’t scale linearly — it compounds. In one manufacturing client environment I managed, a FortiGate 6500F was running 23 VDOMs after four years of organic growth. The original design had no documented inter-VDOM routing policy, no consistent naming convention, and 47 policy conflicts between VDOMs that nobody had noticed because traffic was simply being dropped silently. This post documents the lessons learned from that cleanup and the best practices that prevent these problems from developing in the first place.

FortiOS 6.4 through 7.4 has introduced significant improvements to VDOM management, including enhanced ADOM (Administrative Domain) integration when paired with FortiManager, and the Policy Package concept that allows consistent policy deployment across multiple VDOMs. Understanding these features — and their limitations — is essential for any engineer operating a multi-tenant FortiGate environment.

Understanding VDOM Architecture: The Three-Layer Model

Before writing a single policy, your VDOM architecture needs a deliberate design. The most stable model I’ve worked with uses three logical layers:

Layer	VDOM Role	Count	Interface Assignment
Management	Device administration, NTP, FortiGuard, logging	1 (fixed)	Dedicated OOB interface
Shared Services	DNS, AD, shared infrastructure	1–2	Trunk VLAN
Tenant	Isolated customer traffic	One per tenant	Dedicated VLAN or physical port
Internet Gateway	Shared internet egress	1–3 (per ISP)	WAN interfaces

The critical rule: never mix management traffic with tenant traffic. In three of five MSP environments I audited, the management VDOM was also handling customer internet traffic, which meant a single misconfigured policy could expose device administration to customer networks.

VDOM Configuration: CLI Fundamentals

Most engineers learn VDOM management through the GUI, which abstracts away details that matter for troubleshooting. Understanding the CLI is essential.


# Create a new VDOM
config vdom
    edit tenant-acme
    next
end

# Assign an interface to a VDOM
config system interface
    edit port3
        set vdom tenant-acme
        set mode static
        set ip 10.50.1.1 255.255.255.0
        set allowaccess ping https ssh
        set alias "ACME-LAN"
    next
end

# Verify VDOM interface assignments
show system interface | grep -A 5 "set vdom"

# Switch context to a specific VDOM
config vdom
    edit tenant-acme
end
# Now all commands execute within tenant-acme context

# Return to global context
end

# View all VDOMs and their status
diagnose sys vd list
# Output shows: name, ref, total_sess, total_sess6, flags, traffic

Inter-VDOM Routing: The Most Common Design Error

Inter-VDOM routing is where most multi-tenant designs break down. The two available mechanisms — VDOM links and NPU VDOM links — have different performance characteristics and management overhead.


# Create a software VDOM link (standard)
config system vdom-link
    edit "acme-to-shared"
        set vcluster-id 1
    next
end

# Assign link endpoints to each VDOM
config system interface
    edit "acme-to-shared0"
        set vdom tenant-acme
        set ip 172.16.100.1 255.255.255.252
        set type vdom-link
    next
    edit "acme-to-shared1"
        set vdom shared-services
        set ip 172.16.100.2 255.255.255.252
        set type vdom-link
    next
end

# Add static route from tenant VDOM to shared services
config vdom
    edit tenant-acme
end
config router static
    edit 1
        set dst 10.0.0.0 255.0.0.0
        set device "acme-to-shared0"
        set gateway 172.16.100.2
    next
end

# Verify VDOM link connectivity
diagnose netlink vdomlink list
diagnose sys vd list | grep acme

In environments with more than 10 VDOMs, I strongly recommend NPU VDOM links (npu-vlink) on platforms that support hardware acceleration. A 2023 test on FG-2600F showed inter-VDOM throughput of 31 Gbps with NPU links versus 4.2 Gbps with software links under identical conditions.

Policy Management Across VDOMs: Consistency Without FortiManager

Without FortiManager, maintaining consistent policies across multiple VDOMs is a manual discipline problem. These are the techniques that work at scale:

Address Object Naming Convention


# Consistent naming prevents "what does this object mean?" questions
# Format: [VDOM]-[Type]-[Description]
config vdom
    edit tenant-acme
end
config firewall address
    edit "acme-srv-webservers"
        set type iprange
        set start-ip 10.50.10.10
        set end-ip 10.50.10.20
        set comment "ACME web tier - 10 servers - added 2024-02-01"
    next
    edit "acme-grp-endpoints"
        set subnet 10.50.1.0 255.255.255.0
        set comment "ACME end user subnet"
    next
end

# Service group with clear naming
config firewall service group
    edit "acme-svc-webapp"
        set member "HTTP" "HTTPS" "tcp-8080" "tcp-8443"
        set comment "ACME app services"
    next
end

Policy Baseline Template


# Every tenant VDOM starts with this baseline set of policies
# Policy 1: Block known bad
config firewall policy
    edit 1
        set name "BLOCK-Known-Threats"
        set srcintf "any"
        set dstintf "any"
        set srcaddr "Threat-Intel-Feed"
        set dstaddr "all"
        set action deny
        set schedule "always"
        set service "ALL"
        set logtraffic all
        set comments "Block threat intel - updated weekly"
    next
end

# Policy 2: Allow DNS to shared resolver only
config firewall policy
    edit 2
        set name "ALLOW-DNS-to-Resolver"
        set srcintf "port3"
        set dstintf "acme-to-shared0"
        set srcaddr "all"
        set dstaddr "shared-dns-servers"
        set action accept
        set schedule "always"
        set service "DNS"
        set logtraffic utm
    next
end

# Policy 99: Explicit deny-all with logging
config firewall policy
    edit 99
        set name "DENY-ALL-Logged"
        set srcintf "any"
        set dstintf "any"
        set srcaddr "all"
        set dstaddr "all"
        set action deny
        set schedule "always"
        set service "ALL"
        set logtraffic all
        set comments "Explicit deny-all - replaces implicit deny for visibility"
    next
end

Resource Allocation: Preventing Tenant Starvation

One tenant with high traffic can starve other tenants on shared hardware. FortiGate provides several mechanisms to prevent this, but they require explicit configuration.


# Set VDOM resource limits (FortiOS 6.4+)
config vdom
    edit tenant-acme
end
config system vdom-property
    set session-count-max 50000
    set ipsec-phase1 100
    set ipsec-phase2 200
    set dialup-tunnel 50
    set firewall-policy 500
    set log-disk-quota 2048
next
end

# Verify current resource usage per VDOM
diagnose sys session full-stat | grep -A 10 tenant-acme

# Monitor per-VDOM traffic
diagnose netstat | grep tenant-acme

# CPU and memory allocation monitoring
diagnose sys vd list
# The 'total_sess' column shows active session count per VDOM

In my 23-VDOM environment, we discovered that one tenant VDOM was consuming 78% of total session table capacity due to a misconfigured application that opened thousands of short-lived connections. Setting session-count-max to 50,000 per tenant VDOM contained the problem without impacting other tenants.

Auditing Multi-VDOM Environments

Auditing a VDOM environment requires a different approach than single-context firewalls. You need visibility across all VDOMs simultaneously.


# List all policies across all VDOMs (from global context)
config global
end
diagnose firewall iprope show all-vdoms

# Check policy hit counts across VDOMs
diagnose firewall iprope show 100004
# Run this from within each VDOM context

# Backup all VDOM configurations individually
config vdom
    edit tenant-acme
end
execute backup config tftp acme_backup_$(date +%Y%m%d).conf 192.168.100.10
end

# Full system backup (includes all VDOMs)
execute backup full-config tftp full_backup.conf 192.168.100.10

# Audit which VDOMs have admin access enabled
show system interface | grep -E "allowaccess|vdom"

For comprehensive policy analysis across all VDOMs, automated tools significantly reduce audit time. The APO Tool for FortiGate policy analysis supports multi-VDOM configuration files and can identify issues across all tenant VDOMs in a single pass.

Common VDOM Management Mistakes

Mistake	Impact	Detection	Fix
Mixing management and tenant VDOMs	Admin exposure to customer networks	Check VDOM assignments of admin interfaces	Separate management VDOM
No resource limits on tenant VDOMs	One tenant can starve others	`diagnose sys vd list`	Set session-count-max per VDOM
Duplicate address objects across VDOMs	Inconsistent policy enforcement	Export configs, compare address objects	Standardize naming, document shared objects
No inter-VDOM routing policy	Accidental trust escalation	Check VDOM link policies	Explicit allow/deny on VDOM link interfaces
Implicit deny without logging	No visibility into blocked traffic	Missing explicit deny-all policy	Add policy 99 deny-all with logtraffic all

FortiManager Integration for Larger Deployments

Beyond 10 VDOMs or 3 physical FortiGate devices, manual VDOM management becomes unsustainable. FortiManager’s Policy Package and ADOM features address this directly:


# Prepare FortiGate for FortiManager management
config system central-management
    set type fortimanager
    set fmg "192.168.100.200"
    set fmg-source-ip 192.168.1.1
end

# Authorize from FortiManager side
# (FortiManager CLI)
execute device register [serial_number]

# Verify management connection
diagnose fdsm stat
get system central-management

# After FortiManager connection, verify policy sync
diagnose debug application fgfmd -1
diagnose debug enable

With FortiManager, you can push the same baseline policy package to all tenant VDOMs simultaneously, then override specific policies per tenant as needed. This approach reduced our policy deployment time from 4 hours (manual per-VDOM) to 12 minutes across all 23 VDOMs.

HA Considerations in Multi-VDOM Environments


# HA configuration in VDOM environments
config system ha
    set group-id 1
    set group-name "VDOM-Cluster"
    set mode a-p
    set password "cluster-secret"
    set hbdev port7 50 port8 50
    set session-sync-dev port9
    set override enable
    set priority 200
end

# Verify HA sync includes all VDOM configurations
diagnose ha dump
diagnose ha compare-config

# Check per-VDOM session sync status
diagnose ha show-dev-list

# Force HA sync after large config change
execute ha synchronize stop
execute ha synchronize start

Monitoring and Alerting for Multi-VDOM Environments


# SNMP configuration for per-VDOM monitoring
config system snmp community
    edit 1
        set name "monitoring"
        config hosts
            edit 1
                set ip 192.168.100.50
                set ha-direct enable
            next
        end
    next
end

# Syslog configuration — send all VDOM logs to central collector
config log syslogd setting
    set status enable
    set server "192.168.100.100"
    set facility local7
    set port 514
    set source-ip 192.168.1.1
end

# Set log filter to include VDOM name in all log entries
config log syslogd filter
    set severity information
    set forward-traffic enable
    set local-traffic enable
end

# Verify logs include vd= field
execute log filter category traffic
execute log display | head -5
# Look for "vd=tenant-acme" in log entries

For compliance-related policy review across VDOMs, see the automated compliance checking guide for NIST 800-53 controls, which covers multi-context device auditing.

Conclusion

Multi-VDOM FortiGate management is fundamentally a discipline problem, not a technology problem. The CLI commands exist to do everything correctly — the challenge is enforcing consistency across VDOMs and over time as different engineers make changes.

The three practices with the highest impact on operational stability are: strict separation of management traffic into its own VDOM, per-VDOM resource limits to prevent tenant interference, and a documented policy baseline that every tenant VDOM starts from. Everything else builds on these foundations.