Domain 2 Firewall policies & authentication
trapmemorisedefault valuenew in 7.6
§2.1 Firewall policies
Policies are matched top to bottom, first match wins, then the implicit deny at the bottom.
The implicit deny policy is policy ID 0. When debug flow says policy 0, nothing matched.
Match criteria: incoming interface, outgoing interface, source (address / user / device), destination (address, VIP, Internet Service), service, schedule, action.
Policy ID is not policy order. The GUI sequence number is order; IDs are permanent and non-sequential. An exhibit listing IDs 3, 1, 7 in that order means that is the evaluation order — do not re-sort them in your head.
Other things exhibits hide: a specific policy placed below a broader one never matches. A disabled policy still appears in the config extract — check the set status line. Internet Service objects can only be a source or a destination, never both.
Inspection mode and NGFW mode
Each policy is set to flow-based or proxy-based individually.
NGFW profile-based (the default): security profiles attach to policies.
NGFW policy-based: applications and URL categories become direct policy match criteria — and central NAT becomes mandatory.
"Traffic dropped right after I edited a policy" → firewall-session-dirty. Set to check-all, existing sessions are re-evaluated after any policy change. Set to check-new, only new sessions are affected.
§2.2 SNAT and DNAT
SNAT — IP pool types
Central SNAT lifts NAT out of the policy into its own table, evaluated top-down independently of policy order.
DNAT with virtual IPs
Order of operations: DNAT happens before the routing decision. The FortiGate therefore routes toward the mapped (internal) address, not the external one. This single fact answers a lot of VIP questions.
The firewall policy dstaddr must reference the VIP object, never the internal address.
FortiGate auto-replies to ARP for the VIP external IP — that is why a VIP on the interface subnet just works.
VIP types: static NAT, port forwarding, load balance.
set nat-source-vip forces reverse SNAT for hairpin scenarios.
The classic broken-port-forward exhibit is one of: no firewall policy at all, a policy whose srcaddr is too narrow, or the VIP's external interface not matching the ingress interface. A VIP by itself does nothing.
§2.3 Firewall authentication
Active = the user is prompted (captive portal or a policy-triggered challenge). Passive = credentials learned elsewhere (FSSO, RSSO).
LDAP
For Active Directory the Common Name Identifier is sAMAccountName, not cn. Exhibits show cn as a plausible wrong answer constantly.
RADIUS
Ports UDP 1812 (auth) and 1813 (accounting). Legacy: 1645 / 1646.
Auth types: PAP, CHAP, MS-CHAP, MS-CHAPv2, or auto.
Fortinet vendor-specific attribute is VSA 12356 and can push group membership.
auto tries PAP → MS-CHAPv2 → CHAP. If the server only accepts MS-CHAPv2 and you hard-set PAP, authentication fails. That is a standard exhibit.
§2.4 FSSO — the biggest gap for NOC engineers
Two deployment styles
The four classic "FSSO users can't get through" causes: