NSE7 Part 4: VLANs and VDOMs at Enterprise Scale

One Box, Many Firewalls already covers the VRF-versus-VDOM framing, inter-VDOM links, and the MSSP three-customer scenario in detail. This post assumes that background and stays narrowly on the two pieces the NSE 7 blueprint calls out specifically: the virtual LAN switch, and the segmentation/inter-VDOM-routing use cases as design decisions rather than configuration mechanics.

VLANs on FortiGate

A VLAN interface on FortiOS is a sub-interface bound to a physical or aggregate interface plus an 802.1Q tag, with its own IP addressing, firewall policies, and routing table entry, same as any other interface:

config system interface
    edit "vlan100-finance"
        set vdom "root"
        set interface "port3"
        set vlanid 100
        set ip 10.30.100.1 255.255.255.0
        set allowaccess ping https ssh
    next
end

That much is NSE4 territory. The enterprise-scale question NSE 7 adds is where VLAN tagging happens relative to the FortiGate at all, which is where the virtual LAN switch comes in.

The Virtual LAN Switch

A switch interface (config system switch-interface or, for the newer software-switch construct, config system virtual-switch) groups multiple physical FortiGate ports into a single logical Layer 2 broadcast domain behind one IP address, without an external switch. This isn’t the same as FortiLink-managed FortiSwitch integration (covered in NSE6), where the FortiGate manages genuine external switch hardware. A virtual LAN switch is the FortiGate’s own ports acting as a switch, useful on smaller platforms or branch deployments where a handful of directly-attached devices don’t justify a dedicated switch, but every port in the group shares one broadcast domain and one set of firewall policies as far as the rest of the FortiGate is concerned.

The design distinction the exam cares about: a virtual LAN switch collapses multiple physical ports into one logical interface (many physical, one logical), while VLAN tagging on a single physical or aggregate interface does the reverse (one physical, many logical). An enterprise branch design commonly uses both at once: an aggregate uplink to a real switch carrying multiple 802.1Q-tagged VLANs, alongside a small virtual LAN switch group of directly-attached out-of-band management ports that don’t need trunking at all.

VDOM Types, Revisited for Design Decisions

The earlier VDOM post covers the mechanics of the three VDOM types. At enterprise scale the question shifts from “what does each type do” to “which one does this specific requirement actually need”:

NAT/Route VDOMs are the default, and the right choice whenever the requirement is genuine traffic separation with independent routing tables, independent policy, and independent NAT behavior between VDOMs: the MSSP multi-tenant pattern, or splitting a large enterprise into business-unit VDOMs that shouldn’t be able to route to each other by default.

Transparent VDOMs bridge traffic at Layer 2 with no routing decision at all, useful for inserting a FortiGate’s inspection into an existing Layer 2 segment without renumbering anything on either side. This shows up more than the NSE4 curriculum suggests in enterprise designs where a security team is asked to add inspection to an existing data center segment that a different team owns the IP addressing for, and renumbering isn’t on the table.

Admin VDOMs (the management VDOM specifically) exist purely to isolate the FortiGate’s own management plane traffic (GUI/CLI access, FortiGuard queries, logging) from any customer or business-unit VDOM’s data plane. This matters more in MSSP designs than single-enterprise ones: a management VDOM ensures that even if a customer VDOM is fully compromised, the attacker doesn’t have a data-plane path to the FortiGate’s own management interface.

Use Case: Segmentation Through VLANs

The straightforward version of this use case is business-unit or building-level separation: Finance on VLAN 100, HR on VLAN 200, Guest on VLAN 300, each with its own firewall policy set controlling what can reach what. The NSE 7-level version adds a wrinkle NSE4 doesn’t dwell on: VLAN segmentation and VDOM segmentation solve different problems, and conflating them is a common design mistake.

VLANs segment at Layer 2/3 within a shared administrative and policy context: one routing table (per VDOM), one FortiGuard security profile set, one administrator group, unless policy explicitly isolates traffic between VLANs. VDOMs segment the FortiGate’s own control plane: independent routing tables, independent policy sets, independently assignable administrators. A design that needs “Finance traffic must never be inspected against the same IPS sensor tuning as Guest traffic, and a Finance-only administrator must not be able to see Guest firewall policy at all” needs VDOMs. A design that just needs “Finance and Guest traffic must not reach each other by default, but the same admin manages both” needs VLANs and firewall policy, and reaching for VDOMs there is unnecessary complexity that costs a routing table and a chunk of the platform’s VDOM license ceiling for no real gain.

Use Case: Internet Access Through Inter-VDOM Routing

The other named use case is the practical mechanics of getting VDOM-isolated traffic to shared internet egress without giving every VDOM its own WAN circuit. The pattern: a dedicated egress VDOM (commonly named something like internet or edge) owns the actual WAN interfaces, SD-WAN configuration, and default route, while customer or business-unit VDOMs each have an inter-VDOM link back to the egress VDOM and a default route pointed at it.

config system vdom-link
    edit "link-finance-edge"
    next
end

config system interface
    edit "link-finance-edge0"
        set vdom "finance"
        set type vdom-link
    next
    edit "link-finance-edge1"
        set vdom "edge"
        set type vdom-link
    next
end

Firewall policy on both ends of the inter-VDOM link controls exactly what’s allowed to cross it, same as any other interface pair. The design payoff: SD-WAN complexity, ISP relationships, and WAN interface management live in exactly one place (the edge VDOM), while every tenant or business-unit VDOM gets internet access through a policy-controlled link rather than needing its own independently-managed WAN configuration. This is the same pattern the Fortinet SD-WAN Hub Placement series describes at the network level, applied here within a single chassis instead of across a WAN.

The exam-relevant failure mode to watch for: forgetting that the inter-VDOM link needs firewall policy on both the tenant-side and edge-side interfaces, not just one. A tenant VDOM policy allowing traffic out toward the link is necessary but not sufficient. The edge VDOM also needs a policy permitting that traffic to actually egress toward the internet interface, and it’s easy to configure the tenant side, watch traffic reach the link, and assume the design works, without confirming the return leg on the edge VDOM was ever built.

Licensing and Scale Ceilings

Worth stating plainly since it’s an easy trap in a design question: VDOM count is capped per platform and per license (get system status shows the current max), and adding VDOMs beyond the base allocation on hardware platforms typically requires a VDOM license upgrade, not just a config change. A design that proposes ten VDOMs on a platform whose base license allows two is not a valid answer regardless of how sound the segmentation logic is, and the exam has been known to test exactly this kind of “the architecture is right but the platform can’t actually do it” scenario.

Part 5 moves from segmentation to the SD-WAN fabric riding on top of it: direct internet access topologies, SD-WAN monitoring, and the traffic distribution mechanics that Part 10 will go much deeper on once BGP and OSPF are on the table.