NSE4 Part 3: Firewall Policies & NAT

NSE4 Part 3: Firewall Policies & NAT

Part 3 of the NSE4 series. This post covers Lessons 3 and 4 — firewall policies and Network Address Translation. Together these produce more exam questions than any other topic; if you have to be sharp on one area, it’s this one.

How a packet finds a policy

When a packet hits a FortiGate, it walks an ordered list of matching steps:

1. Ingress interface — the policy’s source interface must match.
2. Source address — IP, range, group, FQDN or geographic object.
3. Destination interface — egress interface (or any).
4. Destination address — same object types as source.
5. Service — protocol/port object.
6. Schedule — time window must currently be active.

The first policy in the list that matches all six is applied. Order matters — more specific rules go above less specific ones. The GUI shows policies in sequence order but each policy also has a stable internal policy ID that doesn’t change when you reorder.

show firewall policy           ; full config including IDs
diagnose firewall iprope show 100004    ; per-policy hit counters

Action and the implicit deny

Every policy has an action: accept, deny, or ipsec. There is also an implicit deny rule at the very bottom (policy ID 0) that drops everything not explicitly allowed. Logging the implicit deny is off by default — turn it on to see what’s being silently rejected:

config firewall policy
    edit 0
        set logtraffic all
    next
end

NGFW modes

A VDOM operates in one of two NGFW modes:

• Profile-based (default) — application control, web filter, AV etc. attach as profiles to each policy.
• Policy-based — application and URL category become first-class policy match criteria; profiles still exist but the policy itself can match on Facebook or social-media.

Set per VDOM:

config system settings
    set ngfw-mode policy-based   ; or profile-based
end

Switching mode rewrites your policy structure — exam questions will show one mode and ask why a policy isn’t matching.

NAT — two flavours

FortiGate offers two ways to express NAT:

Policy NAT (default). SNAT and DNAT live inside the firewall policy. Enable NAT checkbox on the policy itself; destination NAT is a Virtual IP (VIP) object referenced as the destination address.

Central NAT. SNAT and DNAT live in dedicated tables (Central SNAT, DNAT & VIPs) that match traffic before policy evaluation. The policy itself just allows the traffic. Useful when many policies need the same NAT treatment. Enable per-VDOM:

config system settings
    set central-nat enable
end

Only one mode at a time per VDOM.

SNAT and IP pools

Default SNAT uses the egress interface IP with port translation. For more control, create an IP pool:

Pool type	Behaviour
Overload	Many internal → one external IP, with port translation. Default.
One-to-one	Static 1:1 mapping while session is active.
Fixed port range	Pre-allocate port ranges per internal IP.
Port block allocation (PBA)	Block of ports per internal IP, useful at carrier scale.

Reference an IP pool from the policy with set ippool enable and set poolname "...".

DNAT and VIPs

A Virtual IP maps an external IP/port to an internal IP/port. Two key VIP types:

• Static NAT VIP — full inbound mapping, often used for “publish a web server”.
• Server load balance VIP — VIP with multiple real servers and a health check. Distributes inbound connections.

config firewall vip
    edit "web-vip"
        set extip 198.51.100.10
        set extintf "wan1"
        set mappedip "10.10.10.20"
        set portforward enable
        set extport 443
        set mappedport 443
    next
end

Then reference the VIP as the destination address in a firewall policy from wan1 to the inside zone.

Session helpers

Some protocols (FTP active mode, SIP, RTSP, PPTP, TFTP) negotiate secondary connections inside their control channel. Session helpers parse the control channel and pin-hole the firewall for the secondary flow. They are enabled by default for common protocols:

show system session-helper
diagnose sys session list   ; see live sessions, including helper-created ones

If a SIP or active-FTP setup mysteriously fails after a NAT, the helper is the first place to look.

Diagnostics

The two most useful tools for policy and NAT troubleshooting:

diagnose debug flow filter saddr 10.10.1.50
diagnose debug flow filter daddr 198.51.100.10
diagnose debug flow trace start 100
diagnose debug enable

This walks the packet through every decision point — policy match, NAT, route, anti-replay, session creation. If a policy “isn’t working”, flow trace tells you within seconds whether it’s a policy mismatch, a route problem, or a NAT collision.

diagnose sys session filter dst 198.51.100.10
diagnose sys session list

shows the live session table including the post-NAT 5-tuple and which policy ID created the session.

Part 4 covers firewall authentication, FSSO and certificate operations.