I85PREP
⌘ K
Fortinet NSE 7 study materials
Fortinet NSE 7 study resources

Fortinet NSE 7: Firewall policy, NAT, and authentication

Fortinet NSE 7 · Work through your exam, one topic at a time.

All guide sections

Firewall policy, NAT, and authentication

Firewall Policy

First match wins, then nothing matches

Policies are evaluated top-down and the first full match wins - interface or zone, source address, user/group, device, destination address, service, schedule, and (optionally) application or URL category. The implicit deny at the bottom drops all remaining traffic and by default logs nothing, so questions about "traffic silently dropped" usually point at ordering or at missing logging on the deny policy.

Traps to watch:

  • No egress interface field. Policy direction is defined by the incoming interface only; the outgoing interface comes from routing or SD-WAN. A policy cannot "use port2 to reach the internet."
  • Editing does not affect live sessions. Address, NAT, or profile changes apply to new sessions only; clear matching sessions (diagnose sys session filter then diagnose sys session clear) or the fix appears not to work.
  • Shadowing. A broad any-service allow above a specific policy makes the specific policy unreachable; policy hit counters and diagnose firewall iprope lookup prove it.
  • NAT mode conflicts. With Central NAT enabled per VDOM, set nat enable in policies is ignored; source translation comes from the central SNAT table.
  • Authentication inside policy. Active auth prompts the user; passive auth relies on an existing session or captive portal and a group must match before any traffic passes. Firewall user timeouts, not policy timeouts, govern re-authentication.

Rule of thumb: order policies specific-to-general, give every deny policy logging, attach profiles on the same policy that permits the traffic, and treat policy ID as the audit anchor - log entries reference it, so renaming or deleting a policy changes the meaning of historical logs. NGFW policy mode replaces address/service-based rules with application-based security policies and forces central SNAT.

NAT

Source NAT is a policy attribute; destination NAT is an object

Source NAT exists in two mutually exclusive forms per VDOM: policy NAT (set nat enable, translating to the egress interface address unless an IP pool is referenced) and Central NAT (a central SNAT table evaluated independently of policy NAT). Once Central NAT is on, per-policy nat enable does nothing - a favourite distractor.

Destination NAT is always an object: a VIP maps an external address/port to an internal address/port. A VIP in a policy's destination is translated implicitly; you do not enable nat to get DNAT. Enabling nat on the same policy additionally source-NATs the connection, which is what makes hairpin (internal client reaching an internal server by its public IP) work through a policy whose incoming and outgoing interface are the same internal interface.

match-vip lets a policy whose destination is the server's real (mapped) address still match traffic addressed to the VIP - needed when rules are written against real server IPs.

IP pool types and their use: overload (PAT, many-to-one), one-to-one (fixed mapping), fixed-port-range, and port-block-allocation (carrier-grade NAT with deterministic blocks). Pools sharing a subnet with the FortiGate interface need arp-reply enabled so the FortiGate answers ARP for pool addresses.

Worked rule of thumb: if return traffic is missing, check (1) SNAT source address on the server, (2) route back to the translated address, (3) whether the VIP appears as the policy destination, and (4) session detail with diagnose sys session filter dport <port> + diagnose sys session list.