Firewall Policies and NAT
The policy table is the decision engine: route lookup, interface pair, address/service/schedule/user match, first match wins, then NAT and inspection behavior.
Mental model
A FortiGate policy decision is not just a source and destination address match. The firewall considers ingress interface, route-derived egress interface, source, destination, service, schedule, users, policy order, and inspection mode. NAT then changes addressing either at the source side, destination side, or through central NAT rules.
Packet decision order
- Packet enters an ingress interface.
- FortiGate checks routing to determine the likely egress interface.
- Policy lookup narrows candidates by interface pair or zone.
- Policy table is evaluated top-down; first match wins.
- Security profiles, NAT, shaping, logging, and session handling are applied.
- If no policy matches, policy ID 0 silently drops unless logging is enabled.
Policy types
| Policy type | Controls | Exam relevance |
|---|---|---|
| IPv4/IPv6 firewall policy | Transit traffic passing through FortiGate. | Core behavior for almost every lab. |
| Local-in policy | Traffic destined to FortiGate itself. | Protects management, BGP, OSPF, VPN negotiation, FGFM, and admin access. |
| DoS policy | Rate-based protection at interface edge. | Threat mitigation and edge hardening. |
| Proxy policy | Explicit proxy traffic. | Useful when testing explicit proxy and PAC behavior. |
| Traffic shaping policy | Bandwidth and priority behavior. | SD-WAN and application experience scenarios. |
Security mode distinction
Profile-based mode attaches security profiles to a policy: AV, IPS, web filter, app control, SSL inspection, and so on. NGFW policy-based mode pushes application and URL category matching into the policy itself. The tradeoff matters because engineers sometimes expect profile behavior in a mode where the controls live somewhere else.
NAT patterns
| NAT type | What changes | Typical use |
|---|---|---|
| Interface SNAT | Source becomes outgoing interface IP. | Simple internet access for internal clients. |
| IP pool SNAT | Source becomes an address from a pool. | Predictable public source IPs, partner access, CGNAT-style planning. |
| VIP / DNAT | Destination becomes an internal server. | Publishing an internal service externally. |
| Central NAT | NAT rules are separate from firewall policies. | Large or complex deployments where translation policy needs its own table. |
Object dependencies
- Address objects: can be subnets, ranges, FQDNs, wildcard FQDNs, geography, dynamic objects, or MAC objects.
- FQDN objects: require working FortiGate DNS. If DNS fails, policy matching can fail in a way that looks unrelated.
- Zones: simplify policy design, but zone membership changes how interfaces are referenced.
- Services: match protocol and port; a wrong service object can make everything else look correct while traffic still fails.
- Schedules: can make a policy disappear from matching outside the active window.
CLI anchors
diagnose firewall policy-lookupSimulate which policy should match a packet.
show firewall policy <id>Inspect exact policy configuration.
diagnose debug flow filter addr <ip>Constrain flow debug before tracing.
diagnose sys session listConfirm policy ID and SNAT/DNAT behavior.
diagnose firewall ippool listCheck IP pool allocation and exhaustion.
diagnose firewall vip listValidate VIP objects.
show firewall central-snat-mapReview central SNAT rules.
config firewall policy; move <id> before <id>Correct policy order.
NSE 8 WATCHPOINTS
- A VIP must be referenced as the destination address in the policy, not the real internal server IP.
- When
intrazone denyis set, traffic between members of the same zone still needs an explicit policy. - FQDN objects silently depend on FortiGate DNS. Broken DNS can make a correct-looking policy fail.
- Policy order can make a specific allow useless if a broader deny appears above it.
- Central NAT removes per-policy NAT controls, which can confuse troubleshooting if you expect
set nat enableunder the policy. - SIP ALG can fix some NAT traversal problems and create others. Voice with one-way audio is a classic symptom to investigate.
Lab exam checkpoint
Goal: prove first-match policy behavior and NAT behavior. Create overlapping policies, intentionally place one in the wrong order, validate with policy lookup, fix the order, publish a test service with a VIP, then prove DNAT/SNAT in the session table and logs.