FortiGate VDOMs and Multi-Tenancy — Split-Task, Inter-VDOM Links and MSP Patterns in 11 Minutes

Why this matters — the office-building rule

Picture a six-floor office building in Hinjewadi, Pune. Same address (one physical FortiGate). Different floors house different companies — floor 2 is a bank, floor 3 a retail chain, floor 4 an insurance broker. Each tenant has its own door (interfaces), its own lift (routing table), its own keys (admin scope), and the ground-floor lobby (the management VDOM) handles shared utilities — internet uplink, FortiGuard updates, monitoring. VDOMs are that office building, made out of firewall.

Get this metaphor and the next 11 minutes are easy. Miss it and an MSP interview at an Indian enterprise, an Indian IT services firm, an Indian IT services firm, an Indian MSP or an Indian security firm ends in the first 90 seconds — because their entire managed-security business runs on shared FortiGate iron.

The three modes — what your interviewer is testing

FortiOS gives you three operating modes, set globally per device. Single VDOM is the default — one implicit `root` VDOM, no multi-tenant separation. Split-task VDOM mode locks the box into exactly two VDOMs — `root` (management-only, no traffic processing) and `FG-traffic` (production policies). It's a security-hardening play, not a multi-tenant play. Multi-VDOM mode is what Anil uses — up to 10 VDOMs free on FortiGate-200F, more with a license uplift, each a complete virtual firewall.

Watch a packet hop across an inter-VDOM link

This is where most candidates get tripped. The interviewer says: "User on Customer-A wants google.com — walk me through the packet path." The right answer names two policy lookups, two routing decisions, and one NAT — all inside the same box. The infographic below summarises the 5 hops as boxes — the visualizer underneath steps through each with narration.

Inter-VDOM link — software path vs NPU offload

The single biggest senior-interview drill is "when does an inter-VDOM link get NPU offload?" because it directly impacts CPU usage on busy MSPs. Default inter-VDOM links are software-only — every packet between VDOMs walks the CPU. On a 12-customer FortiGate-200F at peak hours that adds up fast. NPU-accelerated inter-VDOM links bypass the CPU for established sessions — but require specific hardware conditions.

Decision tree — which VDOM mode for your use case?

Most candidates instinctively pick multi-VDOM mode for everything. That's wrong. The right answer depends on whether you need multi-tenancy, security separation, or just neat defaults. Use this tree.

Configuration walkthrough — Anil enabling multi-VDOM

Anil's clean-room build, sized for the 12-customer MSP load. Note the reboot in the middle.

FG200F # config system global
FG200F (global) # set vdom-mode multi-vdom
FG200F (global) # end

This will disconnect any current sessions. The system will reboot. Continue? (y/n) y

FG200F login: admin
FG200F # config global
FG200F (global) # config system vdom
FG200F (vdom) # edit cust-a
FG200F (cust-a) # next
FG200F (cust-a) # edit cust-b
FG200F (cust-b) # next
FG200F (cust-b) # edit cust-c
FG200F (cust-c) # end

name=root/root index=0 enabled
   uses_global_route=0  uses_global_arp=0
name=cust-a/cust-a index=1 enabled
name=cust-b/cust-b index=2 enabled
name=cust-c/cust-c index=3 enabled
4 vdoms exist; 1 mgmt-vdom; max-vdoms=10 (license: base)

Then Anil creates the inter-VDOM link pair between mgmt (root) and cust-a:

FG200F (global) # config system vdom-link
FG200F (vdom-link) # edit cust-a-vlink
FG200F (cust-a-vlink) # set type ppp
FG200F (cust-a-vlink) # next
FG200F (vdom-link) # end

FG200F (global) # config system interface
FG200F (interface) # edit cust-a-vlink0
FG200F (cust-a-vlink0) # set vdom root
FG200F (cust-a-vlink0) # set ip 10.255.71.1 255.255.255.252
FG200F (cust-a-vlink0) # next
FG200F (interface) # edit cust-a-vlink1
FG200F (cust-a-vlink1) # set vdom cust-a
FG200F (cust-a-vlink1) # set ip 10.255.71.2 255.255.255.252
FG200F (cust-a-vlink1) # end

Overlapping subnets — three banks, one 192.168.1.0/24

This is the question every MSP architect dreads in an interview. Three customers, all using 192.168.1.0/24 internally (because everyone copies the same Cisco router default). On a shared FortiGate the answer is "yes, perfectly fine — each VDOM has its own routing table." But routing isn't enough — return traffic needs unique source IPs. The trick is NAT on the mgmt-side of each inter-VDOM link.

The mgmt-VDOM route trap (#1 senior question)

Every senior round at an Indian MSP and an Indian security firm asks some variant of this: "A customer VDOM can't reach FortiGuard for updates — what's the first place you check?" The answer is the default route.

SVG cheat-sheet — the 9 commands you'll use weekly

Print this. Tape it next to your console.

License uplift — 10 free vs paid bump

Every FortiGate (except low-end "F" models which lock at 1) ships with 10 VDOMs included. Adding more requires a VDOM license uplift purchased from Fortinet. The license tier comes in packs (e.g. 25, 50, 100, 250, 500). Anil's FG-200F is on the base tier — sufficient for 12 customers with room. If he wins three more customers, he applies a 25-VDOM uplift before commissioning.

Mode change is disruptive — Anil's change-window discipline

Three mode changes — single → multi-VDOM, single → split-task, split-task → multi-VDOM — all trigger an automatic reboot after set vdom-mode commits. Worse, config does NOT auto-migrate. A single-VDOM box switched to multi-VDOM loses all interface assignments to "root" by default, and you must manually re-home each interface, route, and policy. Anil's rule: backup config, document interface bindings, schedule a 90-minute window, never do this in business hours.