One Box, Many Firewalls: A Practical Guide to FortiGate VDOMs

The question this post keeps getting asked back

Every time the VRF material on this site comes up — MP-BGP and VRFs, route-leaking between VRFs, the VRF1 transport design — the same follow-up question shows up: “couldn’t you just use VDOMs for that?”

Sometimes. Not always. And the difference is the actual subject of this post — because VDOMs and VRFs solve adjacent-looking problems with very different blast radii, and picking the wrong one produces a design that technically works and is miserable to operate.

What a VDOM actually is

A virtual domain partitions a single physical FortiGate into multiple logically independent firewalls. Each VDOM gets its own routing table, its own firewall policies, its own security profiles, and — depending on how you set up administrative scope — its own administrators who can’t see into other VDOMs at all. From the perspective of anyone managing a VDOM day to day, it is a separate firewall. They configure policies, they read logs, they troubleshoot sessions, and none of it touches or is visible from any other VDOM on the same chassis.

That last point is the crux of the distinction from a VRF. A VRF partitions the routing table — it’s a mechanism for keeping route information separate within what is still fundamentally one firewall, with one policy engine, one administrative scope, one management plane. A VDOM partitions the firewall itself. The packet’s-eye view in Part 3 of the packet-flow series — the routing and policy stage — is where this becomes concrete: a VRF changes which routing table that stage consults; a VDOM changes which entire firewall instance the packet is traversing.

The decision that actually matters: what are you separating, and from whom?

This is where the choice stops being technical and starts being organisational, and it’s worth sitting with before touching any configuration.

Reach for a VRF when the separation is about traffic — keeping route tables distinct so that, say, a guest network’s routes never leak into the corporate table, while the same team configures and operates both. The multi-VRF guest Wi-Fi design is exactly this: one administrative team, one policy philosophy, traffic kept apart at the routing layer because that’s where the separation needs to live.

Reach for a VDOM when the separation is about administration — when two groups of people need genuinely independent control, and “independent” means “can’t see each other’s configuration, policies, or logs,” not just “their traffic doesn’t mix.” The textbook case is a managed-services or MSSP context: each customer gets a VDOM, each customer’s admin team configures and views only their slice, and a breach of one customer’s credentials grants zero visibility into any other customer’s environment. The hub placement series’ MSSP discussion is the design-level version of exactly this scenario — VDOMs are the mechanism that makes “the hub becomes the customer-facing edge” administratively sane rather than a shared-blast-radius nightmare.

The shorthand worth keeping: a VRF answers “how do I keep these routes apart?” A VDOM answers “how do I keep these people apart?” If your honest answer to “who needs to be kept out of what” is “nobody, really, it’s all my team” — you almost certainly want a VRF, and reaching for a VDOM will just add an administrative layer you now have to maintain for no isolation benefit you actually needed.

Inter-VDOM routing: how a packet actually crosses the boundary

Because each VDOM is functionally its own firewall, traffic that needs to move from one VDOM to another doesn’t just “route across” the way it would between VRFs in the same routing instance — it has to traverse a connection between two independent firewall instances. FortiOS provides this via inter-VDOM links: virtual interface pairs that connect two VDOMs, each end behaving like a normal interface with its own IP addressing, routing entries, and — critically — its own firewall policy evaluation.

That last point is the one that catches people designing their first multi-VDOM deployment. Traffic crossing an inter-VDOM link is not implicitly trusted just because it originated on the same physical box. It’s a new session as far as the destination VDOM’s policy engine is concerned, and it gets evaluated exactly the way traffic arriving on any other interface would — full policy lookup, full UTM profile application if configured, full logging. Design the policies on both ends as if the two VDOMs were separate physical firewalls connected by a cable, because from a security-evaluation standpoint, that’s precisely what they are.

The corollary: if you’re used to thinking about the stateful inspection and session-table mechanics as a single continuous process for a flow, an inter-VDOM hop breaks that continuity into two independently-tracked sessions — one in each VDOM. That’s not a quirk to work around; it’s the isolation guarantee actually being honoured at the session layer, and it’s exactly what you’re paying the administrative complexity cost for.

Where VDOMs interact with the rest of the fabric

A few places worth flagging before you design around VDOMs at scale:

Licensing and resource allocation. VDOMs aren’t free — they consume a license entitlement, and depending on the platform, CPU and memory allocation across VDOMs is something you need to actively plan for rather than assume scales linearly. A design that looks clean on a whiteboard (“just give each customer their own VDOM”) needs a sizing conversation with the platform’s actual VDOM limits before it becomes a commitment.

Management scope and FortiManager. If you’re running FortiManager at scale, VDOMs are visible to it as distinct managed entities — which is generally the point (it’s how you delegate template and policy-package management per VDOM to per-customer or per-team scopes), but it’s also another axis of complexity in an already-layered management model. Worth mapping out before the VDOM count grows past the point where you can hold the whole topology in your head.

SD-WAN and VDOMs together. SD-WAN configuration — rules, performance SLAs, overlay membership — is itself scoped per-VDOM. A multi-VDOM SD-WAN deployment means each VDOM runs its own independent SD-WAN configuration, which is powerful (genuinely independent path-selection policy per customer or per business unit) and also means the hub placement and resilience design work has to be done — and maintained — once per VDOM, not once for the box.

A worked scenario: the MSSP hub, three customers

Take the cloud-SASE-leaning hub design from hub placement Part 3 and add the constraint that three separate customer organisations need to operate through it, each with their own admin team and zero visibility into the others:

• Each customer gets their own VDOM: independent routing table, independent firewall policy set, independent SD-WAN configuration and performance SLAs tuned to their applications and their circuits.
• Each customer’s admin team gets scoped administrative access to only their VDOM — they can troubleshoot, adjust policy, and pull logs for their environment, and the platform guarantees they cannot see that any other VDOM exists.
• A shared-services VDOM (or root VDOM, depending on platform version and design preference) handles anything genuinely common — management-plane connectivity, perhaps a shared internet egress — with inter-VDOM links to each customer VDOM, policies on those links written as carefully as if they crossed a WAN boundary, because from the security model’s perspective, they do.

Notice what doesn’t change: the routing, SD-WAN, and resilience design principles from the rest of this series apply identically inside each VDOM. VDOMs don’t replace that design work — they multiply it by the number of independently-operated environments you’re hosting, and buy you the administrative isolation that makes hosting them on shared hardware a defensible thing to do at all.

The one-line summary to carry forward

VRF for traffic separation within a team; VDOM for administrative separation between teams. Everything else in this post is detail in service of that one distinction — get it right, and the rest of the design follows naturally from principles this series has already covered. Get it backwards, and you’ll spend months operating a structure that’s solving a problem you didn’t actually have.