Fortinet NSE 4 common mistakes
Fortinet NSE 4 · Understand the traps and how to avoid them.
Placing a newly created permit policy below an existing broader policy (or at the bottom of the list) and then concluding that the policy 'doesn't work' because traffic is still denied.
Candidates treat firewall policy as an unordered rule set. FortiGate evaluates policies strictly top-down and stops at the first match; a wider policy above will shadow anything beneath it, and anything unmatched falls to the implicit deny.
What to do instead
Before troubleshooting anything else, run Policy Lookup (Policy & Objects > Policy Lookup) or 'diagnose firewall iprope lookup ' to see which policy ID actually matches, then reorder the policy above the one shadowing it.
Configuring the virtual IP as the destination on the outbound (internal-to-internet) policy, or creating an outbound policy with NAT disabled and expecting internet access to work.
Candidates collapse DNAT and SNAT into one mental step. On FortiGate, DNAT (VIP) is applied on the ingress policy as the destination address, while SNAT is applied on the egress policy via 'set nat enable' plus an egress IP pool or 'use outgoing interface address'.
What to do instead
Map it explicitly: VIP object as destination on the inbound policy from WAN; 'set nat enable' on the outbound policy from LAN. Verify with 'diagnose debug flow' that the session shows the translated source and destination addresses in both directions.
Assuming a shaper (shared or per-IP) is in effect simply because it was created under Traffic Shaping, when it was never referenced by a firewall policy or shaping policy.
Shapers are inert objects. They only take effect when bound via 'set traffic-shaper' / 'set traffic-shaper-reverse' on a firewall policy, or referenced by a traffic shaping policy. Candidates also miss that shaping policies are evaluated before firewall policies and only the first matching shaping policy applies.
What to do instead
Confirm the binding path (firewall policy fields or shaping policy), verify the shaper is shared vs per-IP as intended, and check counters with 'diagnose firewall shaper traffic-shaper list' and 'diagnose firewall iprope list' to prove traffic is hitting the shaper.
Leaving SSL/SSH inspection on 'certificate-inspection' (or no inspection profile at all) on an HTTPS-heavy policy and then expecting antivirus, web filter categories, or application control to block or log content.
Candidates confuse SNI/CN-based inspection with full decryption. Certificate inspection only exposes the certificate fields, so content-based engines have nothing to inspect on encrypted flows.
What to do instead
Use a deep-inspection profile for content-based enforcement, install the FortiGate CA certificate on clients (or use a trusted CA), and set exempt entries only for categories that genuinely cannot be decrypted (financial, health).
Bringing up an IPsec tunnel with parameters that 'look right' on each side - same PSK, same remote gateway - but with mismatched phase 1 proposals (encryption/authentication/DH group) or non-mirrored phase 2 selectors.
Candidates verify the visible fields (peer address, pre-shared key) and skip the cryptographic proposal list. Phase 1 requires at least one matching proposal; phase 2 requires the local selector on one end to equal the remote selector on the other.
What to do instead
Compare proposals field by field on both peers, mirror the phase 2 local/remote subnets, and read 'diagnose vpn ike log-filter name ' plus 'diagnose vpn tunnel list' / 'get vpn ipsec tunnel details' to see which phase fails.
Creating LDAP/RADIUS/FSSO user groups but not referencing the group in the source field of the firewall policy, then reporting that authentication 'is not working'.
Candidates treat authentication as a global service. On FortiGate, authentication is per-policy and only triggered when a user or user group appears in the policy source; policies with 'all' as source never prompt.
What to do instead
Put the user group in the source of the policy that should trigger authentication, verify the LDAP bind DN/base DN and group membership attribute, and test with 'diagnose test authserver ldap ' and the Firewall User Monitor.
Assuming multiple SD-WAN rules apply simultaneously, or that adding an interface to an SD-WAN zone is sufficient to steer traffic without a static route pointing at that zone.
Candidates read SD-WAN rules as additive policy. In practice only the first matching rule is used (with an implicit bottom rule handling the remainder), and traffic still needs a route whose gateway resolves through the SD-WAN member or zone.
What to do instead
Order rules by specificity from top to bottom, confirm the underlying static route points to the SD-WAN interface/zone, validate members have gateways and passing SLA health checks, and confirm the selected member with 'diagnose sys sdwan route list' and 'diagnose sys sdwan health-check'.
Adding a static route for a destination that already has a better route, then assuming the new route is active because it appears in the configuration.
Candidates do not distinguish the configured routing database from the active routing table. Longest-prefix match wins first; among equal prefixes, lower administrative distance wins; equal distance and priority gives ECMP. Connected routes beat static routes.
What to do instead
Compare 'get router info routing-table database' (all candidates) with 'get router info routing-table all' (installed routes), and remember default distances: connected 0, static 10, eBGP 20, OSPF 110, RIP 120.
Running 'diagnose debug flow' and seeing no output, or leaving debug running after the capture and degrading the device.
Candidates issue the flow filter commands but never enable debugging. 'diagnose debug flow' only produces output after 'diagnose debug enable'; symmetric mistakes (forgetting 'diagnose debug disable' and 'diagnose debug reset') leave the console flooded.
What to do instead
Sequence it: 'diagnose debug disable' > 'diagnose debug reset' > 'diagnose debug flow filter addr ' > 'diagnose debug flow show function-name enable' > 'diagnose debug console timestamp enable' > 'diagnose debug enable' > reproduce > 'diagnose debug disable' > 'diagnose debug reset'.
Capturing with 'diagnose sniffer packet' on the physical interface only, and concluding that packets are being dropped because one direction or the tunnel-encapsulated traffic is missing.
Candidates pick a single interface and a low verbosity level. Traffic may traverse a VLAN sub-interface, an IPsec tunnel, or a switch interface, and verbosity 1 hides MAC/IP/port detail needed to correlate a session.
What to do instead
Capture on both sides of the device (ingress and egress interface, or the tunnel interface) with an appropriate filter and verbosity of 4-6, and cross-check timestamps and addresses against 'diagnose sys session filter' / 'diagnose sys session list' to see whether the session was created and which policy it hit.