FortiGate Firewall Policies + NAT — Policy Lookup, Implicit Deny, and Central NAT in 11 Minutes

Why this matters — the dabbawala rule

Think of Mumbai's dabbawalas. Twelve lakh tiffins a day reach the right office through a strict, ordered handoff — the first matching code on the lid wins, even if a more specific code exists further down the route. FortiGate firewall policies work exactly the same. The firewall scans your policy list top-down and the first rule that matches every field (source interface, source IP, destination interface, destination IP, service, schedule, user) wins — no matter how specific a later rule is.

That single sentence is where most L1 candidates pass or fail. Get it right and the next 10 minutes of the interview belong to you.

Two terms every interviewer will test

Policy ID is the immutable handle the firewall uses to remember a policy (you see it in logs, CLI, references). Sequence number is the position in the evaluation list — and that is what determines match order. Don't conflate the two. Reorder policies via the GUI drag-handle (or move CLI), don't change policy IDs.

The top-down match — see it as a flow

The Tuesday ticket Sneha got isn't unique. Every shift, an L1 confuses specificity with position. Here's the same scenario as a flow you can step through.

Central NAT vs per-policy NAT — the silent override

FortiGate gives you two NAT modes. They're mutually exclusive at the VDOM level — the second you enable Central NAT, every per-policy NAT setting you carefully tuned is silently bypassed. This is one of the top three Fortinet interview traps.

Per-policy NAT is what every new FortiGate ships with. Each IP Pool binds inside a single policy via the nat toggle and the ippool reference. Visible, scoped, easy to audit.

Central NAT moves NAT into a separate dedicated policy table (Policy & Objects → Central SNAT). Per-policy nat toggles still appear in the GUI but are ignored — Central NAT decides everything. New admins miss this and lose hours.

VIPs and IP Pools — what each one actually does

Two NAT building blocks confuse interview candidates more than anything else:

• VIP — Virtual IP. Inbound DNAT. You publish 10.30.5.100:443 (DMZ web server) on 203.0.113.10:443 (public). External clients hit the public IP; FortiGate rewrites the destination.
• IP Pool — Outbound SNAT. Internal hosts share one or many public IPs going out. Overload mode (default) does PAT; fixed-port preserves the source port for picky protocols.

Real config — publishing a DMZ web server

Karan at an Indian IT services firm Pune publishes 10.30.5.100 (Apache on the DMZ) on public IP 203.0.113.10. The full FortiOS config:

config firewall vip
    edit "vip-webapp-public"
        set extip 203.0.113.10
        set mappedip "10.30.5.100"
        set extintf "wan1"
        set portforward enable
        set protocol tcp
        set extport 443
        set mappedport 443
    next
end

config firewall policy
    edit 0
        set name "Inbound-Webapp-DMZ"
        set srcintf "wan1"
        set dstintf "dmz"
        set srcaddr "all"
        set dstaddr "vip-webapp-public"
        set service "HTTPS"
        set action accept
        set schedule "always"
        set logtraffic all
    next
end

config firewall policy
    edit 21
        set name "Inbound-Webapp-DMZ"
        set srcintf "wan1"
        set dstintf "dmz"
        set srcaddr "all"
        set dstaddr "vip-webapp-public"
        set service "HTTPS"
        set action accept
        set schedule "always"
        set logtraffic all
    next
end

Debug like an L3 — settle every NAT argument in 60 seconds

Vikram, an L3 at an Indian security firm, doesn't argue about policies. He runs one command. You should too.

diagnose firewall iprope lookup 10.20.1.50 8.8.8.8 80

vd: root/0
iprope_lookup_check_ctx flag(0,0,0,0) tablecnt=14
gnum 100004 flag 0x2 prio 0
iprope_lookup_pol_in_check, prio 0
gnum 100004 (firewall policy)
policy id 7 - matched
    src: 10.20.1.0/24
    dst: 0.0.0.0/0
    action: 1 (accept)
    nat: 1

One command tells you which policy ID matched, whether NAT applied, and the action taken. No tcpdump. No guessing. No "let me check with the network team."

The implicit-deny trap that costs interviews

Most candidates know "there's a deny at the end." Few can explain that it logs. The implicit deny at policy 0 drops the packet, AND when you enable set logtraffic all on the implicit-deny entry (config firewall policy → edit 0 → set logtraffic all), every dropped session shows up in forward traffic logs as policyid=0 with action deny. That's how Vikram's L3 team spots reconnaissance — a flood of policyid=0 entries from one source IP means someone is sweeping.