Firewall Policy and NAT
Core concepts
A FortiGate evaluates traffic against firewall policies top-down and stops at the first match, so policy order is a security control, not a convenience. Each policy defines incoming/outgoing interfaces, source and destination addresses, service, schedule, action, and a profile set. Implicit deny applies to unmatched traffic. Understand the difference between a policy's source NAT (SNAT, typically outbound internet access) and destination NAT (DNAT, typically publishing an internal server via VIP).
NAT mechanics
A VIP maps an external address/port to an internal address/port and requires a policy whose destination is the VIP object. A common trap: forgetting to enable NAT on the outbound policy, or assuming a VIP alone forwards traffic without a matching policy. Central NAT moves NAT configuration out of policies into a dedicated table-questions may ask which mode is active. IP pools provide SNAT address ranges; overload (PAT) is default, while one-to-one and fixed-port-range options change behavior. Hairpin NAT (NAT loopback) lets internal clients reach an internal server via its public VIP and usually needs the internal interface enabled on the VIP or a loopback setting.
Traps to watch
- Policy order: a broad permissive rule above a specific deny silently defeats the deny.
- NAT is applied on the policy matching the traffic's direction; inbound DNAT and outbound SNAT are separate policies.
- Service objects must match the translated port, not only the original port, in some DNAT designs.
- Disabled policies and expired schedules cause silent drops that look like routing failures.
Rule of thumb
Read a policy top-down as a firewall would, and for any NAT question ask two questions: which policy matches first, and is NAT enabled on that policy or in central NAT? If both answers are consistent, the design is usually correct.