FortiGate Architecture — FortiOS, VDOMs, and the Session Table

The one-sentence mental model

FortiOS is the OS. Every FortiGate — from a 60F desktop unit to a 7000-series chassis — runs the same FortiOS build. The hardware differs (ASICs, port count, throughput), but the CLI, GUI, and packet-flow model are identical. Learning one FortiGate = learning them all.

The packet flow (memorize this shape)

Every packet that enters a FortiGate goes through the same steps:

Ingress interface
    ↓
DoS policy check
    ↓
Session table lookup ────────→ [existing session? fast path]
    ↓ (new session)
Routing lookup
    ↓
Policy lookup (firewall policy)
    ↓
NAT (SNAT / DNAT)
    ↓
Security profiles (AV, web filter, app control, IPS, SSL inspection)
    ↓
Egress interface

When something is “not working” on a FortiGate, tracing where along this flow the packet died is the whole troubleshooting workflow. FortiOS gives you diagnose debug flow to watch it in real time.

VDOMs — one box, many virtual firewalls

VDOMs (Virtual Domains) partition a FortiGate into independent logical firewalls:

• Each VDOM has its own routing table, interfaces, firewall policies, admin users.
• VDOMs communicate via inter-VDOM links (internal virtual pairs) or via traditional external interfaces looped back.
• Two modes: NAT/Route mode (typical Layer 3 firewall) and Transparent mode (Layer 2 bump-in-the-wire).
• The root VDOM is always present and hosts global admin configuration (upgrades, HA, SNMP).

Use cases:

• MSP hosting many customers on one box (each customer = one VDOM).
• Enterprise separating prod / dev / DMZ traffic on a single 3000-series.

Admin access

• GUI (HTTPS on port 443 by default — configurable). Every day operations.
• CLI over SSH (port 22 by default). Automation and scripts.
• Console — serial (9600 8N1, RJ45 or USB-C depending on model). Factory reset, boot break.
• REST API — token-authenticated, JSON payloads. Used by FortiManager and CI/CD pipelines.

Every admin login is against a defined admin account with a profile (super_admin, prof_admin, or a custom role). Trusted-host IPs restrict where a given admin can log in from.

Factory reset and boot

Two ways:

1. From the CLI: execute factoryreset — clears everything, reboots.
2. From the boot menu: interrupt during boot (Ctrl+C on console), pick “System reset”. Used when you’ve locked yourself out or corrupted config.

Two flash regions: primary (active firmware) and secondary (previous). execute set-next-reboot secondary reboots into the older image — a lifesaver during upgrades.

The session table

Every stateful connection through the FortiGate has an entry:

session info: proto=6 proto_state=01 duration=42 expire=3540
              policy_id=17 tos=ff/ff ips_view=0
              origin->src=10.10.1.5:52012 dst=8.8.8.8:443
              reply->src=8.8.8.8:443 dst=203.0.113.10:52012

Key fields NSE 4 tests you on:

• policy_id — which firewall policy matched. If you’re troubleshooting, this is the first thing you check.
• proto_state — TCP state (01 = SYN, 05 = ESTABLISHED, etc.).
• expire — how long until this session is aged out.
• origin / reply — the two directions of the flow, with NAT already applied.

CLI: diagnose sys session list or diagnose sys session filter to narrow to one flow.

Common exam / real-world mistakes

1. Assuming policy order doesn’t matter. FortiGate evaluates policies top-down. The first match wins. A permissive “any/any” rule at the top makes every specific rule below it useless.
2. Forgetting NAT is inside the policy, not a separate table. On FortiGate, NAT is a checkbox / IP pool on the firewall policy itself. There’s no separate NAT rule set the way there is on some Cisco platforms.
3. Mixing up transparent mode. In transparent mode the FortiGate becomes a Layer 2 device — no routing, no NAT. Rare in exams but tested.
4. Ignoring the session table when troubleshooting. If a policy change isn’t taking effect, existing sessions still match the old policy until they expire. diagnose sys session clear after major changes.

Cheat strip

FortiOS   same OS across every model. Learn once.
VDOM      logical firewall on shared hardware. Root VDOM = global cfg.
Modes     NAT/Route (L3, default)  |  Transparent (L2 bump).
Access    GUI HTTPS 443  |  CLI SSH 22  |  Console 9600 8N1  |  REST API
Reset     execute factoryreset  OR  boot-menu system reset
Flash     primary + secondary. set-next-reboot secondary = rollback.
Flow      ingress → session lookup → route → policy → NAT → profiles → egress
Session   diagnose sys session list  (check policy_id, proto_state, expire)