FortiGate Firewall Policies — Structure, Order of Operations, NAT Inline

The one-sentence mental model

A FortiGate firewall policy is a row in a spreadsheet. Each row asks: “For this source coming from this interface going to this destination on this port — allow or deny? Apply NAT? Apply security profiles?” The engine reads rows top-down and stops at the first match.

The six required fields

Field	What it means
Incoming Interface	Where the packet enters (physical port, VLAN, SD-WAN member, VPN tunnel).
Source	Address / group / user / device the packet is from.
Outgoing Interface	Where the packet must exit — after routing decides.
Destination	Address / group / FQDN / geography the packet is going to.
Service	TCP/UDP ports (HTTP, HTTPS, custom-app, service groups).
Action	ACCEPT · DENY · IPSEC (put in a specific tunnel).

Optional extras on the same policy:

• NAT — Enable + choose outbound IP (interface / IP pool).
• Security Profiles — AV, web filter, application control, IPS, SSL inspection, DLP.
• Logging — no log / log security events / log all sessions.
• Traffic Shaping — bandwidth limit / guarantee.
• Schedule — always / business hours / custom.

Policy order matters — a lot

FortiGate reads policies top-down. First policy whose (interface + source + destination + service) matches the packet wins. Every subsequent policy is skipped for this flow.

Practical rule: put specific rules on top, general rules at the bottom.

policy id 1  — DENY  guest-VLAN → HR-server            (specific)
policy id 2  — ALLOW guest-VLAN → internet             (broad)
policy id 3  — ALLOW LAN        → internet             (broadest)
policy id 4  — DENY  any        → any                  (catch-all — often implicit)

CLI to reorder: config firewall policy → move <src-id> before <dst-id>.

NAT lives inside the policy

This is the biggest conceptual shift for engineers coming from Cisco ASA or IOS:

On FortiGate, you don’t write a NAT rule separate from a firewall rule. You write ONE firewall policy that says both “allow this traffic” AND “NAT it”.

policy id 5:
  incoming  = internal
  source    = 10.0.0.0/24
  outgoing  = wan1
  dest      = all
  service   = ALL
  action    = ACCEPT
  NAT       = enable (use outgoing interface IP = SNAT to wan1's IP)

That single policy replaces both a Cisco ACL permit + a ip nat inside source command.

For destination NAT (port forwarding), use a Virtual IP (VIP) object as the destination — the VIP defines the external-IP:port → internal-IP:port mapping and the policy just references it.

Central NAT — the other mode

FortiOS has a global toggle: central-nat enable.

• Off (default): NAT lives on each policy (as above).
• On: NAT policies live in a separate central NAT table. Firewall policies just permit/deny; central-NAT rules translate. Closer to the Cisco / Palo Alto model.

Central NAT is preferred when you have many policies sharing the same NAT pool — it deduplicates the NAT config. NSE 4 tests you on knowing the difference and when to switch modes.

Verifying which policy matched

The single most useful diagnostic in FortiOS:

diagnose sys session list
# shows every current session with policy_id + NAT direction

Or a live packet-flow trace:

diagnose debug flow filter addr 10.10.1.5
diagnose debug flow show console enable
diagnose debug enable
diagnose debug flow trace start 10

The flow trace output shows: which policy matched (policy-id=17), what NAT was applied, which security profile ran, and whether the packet was allowed or denied.

Common exam / real-world mistakes

1. Not enabling NAT on the outbound policy. Traffic goes through, then can’t return because the source IP is still the private LAN IP. Symptom: outbound TCP handshake fails. Fix: check the NAT checkbox on the policy.
2. Wrong interface pair. Forgetting to change “outgoing interface” from any when the wrong exit was picked by routing.
3. Address object leaks. Editing a shared address object silently changes every policy using it.
4. Assuming policy changes affect existing sessions. They don’t — existing sessions keep matching the old policy until they age out or you clear them.
5. Overlooking implicit deny. The last policy is always an implicit deny — but it doesn’t log by default. Turn on logging for the implicit-deny rule during troubleshooting to see what’s actually being blocked.

Cheat strip

6 fields   src-if  src  dst-if  dst  service  action
Extras     NAT  |  profiles  |  logging  |  shaping  |  schedule
Order      top-down, first match wins.  Move: move X before Y.
NAT        on the policy (default).  Or global central-NAT table.
DNAT       use a VIP object as the destination.
Trace      diagnose sys session list           (which policy matched)
           diagnose debug flow ...             (live packet path)
Implicit   last rule = deny any. Turn on log to see drops.