Four-VDOM Consolidation with PCI East-West Inspection
Acme Health is consolidating a 1,800-user headquarters onto one FortiGate 600F running FortiOS 7.4. All 60 servers, 1,800 clients, and a 400-device guest WLAN currently sit in the root VDOM behind an any-any policy with no UTM. A new PCI requirement demands isolation of a 24-server cardholder-data zone, and the CISO wants guest traffic in a separate VDOM with no route to internal networks. The FortiGate has two internet links (1 Gbps primary, 500 Mbps backup), one management network, and a FortiAnalyzer. The network team proposes four VDOMs: root, PCI, guest, and mgmt. Security must still inspect east-west traffic from user VLANs to the PCI zone, and administrators need out-of-band access even when the data plane is saturated. The change window is four hours and no new hardware is available. The existing core switch can carry 802.1Q trunks but has no VRFs.
1. Evaluate the proposed four-VDOM design. Where should the inter-VDOM links and firewall policies be placed so that east-west user-to-PCI inspection is enforced in both directions without creating an any-any path?
Read the worked answer
Assessment. Four VDOMs are reasonable, but only if they enforce separate policy domains. Put user VLANs in root, PCI servers in PCI, guest WLAN in guest, and all administrative interfaces in mgmt. Do not put an inter-VDOM link (IVL) between guest and any internal VDOM. Use a dedicated IVL pair-two /30 transit subnets-between root and PCI, and another only if management needs controlled access to devices.
Policy placement. Each VDOM has its own policy table, so an IVL requires a policy in both directions. In root: user VLAN -> IVL, with the UTM/SSL/IPS profile and only required services. In PCI: IVL -> server VLAN, default deny, explicit server/service objects, and logging. The stateful return traffic is allowed by the existing sessions, but a separate PCI-originated policy is needed for PCI-initiated flows. Do not use an IVL-to-any policy; that recreates the any-any path. Apply inspection once on the ingress side where possible, and avoid stacking identical profiles in both VDOMs. For east-west inspection, the root policy is the natural enforcement point because it sees user-to-PCI flows; the PCI policy should be a least-privilege guard. Validate with policy lookup and packet captures in both VDOMs.
2. Guest isolation: what must be verified after migration to prove there is no guest-to-internal path, and which FortiGate features can still leak access?
Read the worked answer
Verify the guest VDOM has only connected routes, a default route to its ISP-facing interface, and no IVL or static route to RFC1918 space. Check get router info routing-table all inside the guest VDOM, then use policy lookup and a source-based ping/trace from a guest client. Confirm DNS and DHCP are local or public, not internal AD DNS; if guest uses internal DNS, that is a data path even without a firewall policy. Also check for leaks through: (1) policy routes or SD-WAN rules that override the default, (2) IPsec or SSL VPN tunnels terminating in guest, (3) 'allowaccess' on guest interfaces for HTTPS/SSH, and (4) IPv6, which is often left enabled and unpolicied. Put a final deny policy in guest, log denied traffic, and test from the guest VLAN to the PCI server subnet, management subnet, and FortiGate interfaces. If the core switch carries both guest and internal VLANs, ensure no Layer 2 adjacency or VRF leakage; a guest VDOM cannot fix a flat Layer 2 network by itself.
3. How would you design management access so administrators can still reach the FortiGate when the data plane is saturated? What limitations remain?
Read the worked answer
Use a dedicated mgmt VDOM bound to a separate physical management interface and management network, not a VLAN on the data trunk. Restrict admin access with trusted hosts, disable unused protocols, and use a console server for out-of-band recovery. If FortiOS supports a management VDOM setting on the model, designate mgmt as the management VDOM so GUI/SSH administration is anchored there. Keep admin access disabled on the data VDOM interfaces. Limitations: a saturated CPU caused by inspection can still delay management, so cap resource use, avoid running full UTM on management traffic, and monitor via SNMP/FortiAnalyzer. A single FortiGate has no control-plane redundancy; the four-hour window should include a console test and a documented rollback. Test by generating a data-plane load and confirming GUI/SSH access from the management network while guest and user traffic is saturated.