Fortinet NSE 7 common mistakes
Fortinet NSE 7 · Understand the traps and how to avoid them.
Treating administrative distance as the tie-breaker that overrides a more specific route - for example, expecting a default route with distance 5 to beat a connected /24 with distance 10, and answering route-selection questions on that basis.
Candidates memorise 'lower distance wins' in isolation and skip the first step of the FortiOS lookup, which is longest-prefix match. Distance and priority only compare routes to the same destination prefix.
What to do instead
Before answering, state the order explicitly: longest prefix match first, then lowest distance, then lowest priority (used for ECMP). Verify in the lab with 'get router info routing-table all' and 'get router info routing-table database', which shows candidate routes and their distance/priority side by side.
Building a policy set with a broad permit near the top (for example LAN-to-WAN all/all) and then a narrower deny, UTM, or authentication policy further down, and expecting the narrow policy to match the traffic it was written for.
FortiOS evaluates policies strictly by sequence number, first match wins, with an implicit deny at the bottom. The GUI's drag-and-drop and 'insert above/below' behaviour makes it easy to lose track of where a new policy actually landed.
What to do instead
Order policies specific-to-general and confirm the real sequence with 'show firewall policy' or the sequence numbers shown in the GUI. Use Policy Lookup (GUI) or 'diagnose firewall iprope lookup' with the exact 5-tuple to prove which policy a flow hits before committing to an answer.
Enabling central NAT and then configuring NAT on individual firewall policies (or the reverse - leaving central NAT on while troubleshooting with per-policy NAT toggles) and expecting the per-policy setting to control translation.
The two NAT models are mutually exclusive in effect: once central SNAT is enabled, policy-level NAT settings are ignored and translation comes only from central-snat-map entries. Lab practice often only ever covers the per-policy model, so the interaction is unfamiliar.
What to do instead
Check the mode first: 'config system settings' → 'central-nat'. If it is enabled, look for the mapping under 'config firewall central-snat-map'; if disabled, NAT is per-policy. Also remember VIPs/DNAT remain policy-referenced in both models. Confirm the actual translation with 'diagnose debug flow' or the session table rather than assuming.
Writing an identity-based policy but leaving the source as 'all' (or a plain address object) and expecting users to be prompted for credentials, or placing that policy below a broader permit so it is never reached.
Firewall authentication is enforced by the matching policy: the user or user group must be the source in that policy, and the policy must actually be the one the traffic matches. Candidates conflate 'I created a user group' with 'authentication is now active for that traffic'.
What to do instead
Put the user group directly in the source field of the specific policy, position that policy above any generic permit, and remember the auth timeout and protocol behaviour ('config user setting', HTTP/HTTPS redirect). Test with Policy Lookup plus a real browser session and check 'diagnose firewall auth list' for the authenticated entry.
Configuring an IPsec VPN where phase 1 comes up but phase 2 never establishes or traffic never passes, because the phase 2 selectors do not mirror between peers or do not match the chosen design (route-based versus policy-based).
Candidates mix the two designs: policy-based tunnels need mirrored local/remote subnet pairs plus a policy with the tunnel as destination interface, while route-based tunnels use 0.0.0.0/0 selectors, a tunnel interface with an IP, routes, and policies on the interface. Copying one design's selectors into the other silently breaks the SA.
What to do instead
Decide the design first. Route-based: 0.0.0.0/0 in both phase 2 directions, assign an IP to the tunnel interface, add static routes and interface-based policies. Policy-based: exact mirrored subnet pairs and policies that reference the tunnel as the outgoing interface. Verify with 'diagnose vpn ike gateway list' and 'diagnose vpn tunnel list' to see which phase fails and what the negotiated selectors actually are.
Enabling SSL VPN portal and settings, then testing only the tunnel logon and declaring success - without a firewall policy from ssl.root to the internal interface, and without routes/policies for the subnets in split-tunnel mode.
The SSL VPN tunnel endpoint (ssl.root) is an interface, so it needs its own policy and routing like any other interface. Candidates focus on the portal and authentication settings, which are the visible configuration, and treat the tunnel as if it bypasses policy.
What to do instead
Create the policy from ssl.root to the internal interface (and back where required), including the destination subnets and profiles; in tunnel/split-tunnel mode ensure a route to the internal subnet exists for the tunnel traffic. Verify the connected user and assigned IP with 'diagnose vpn ssl list' and confirm sessions match the expected policy in the session table.
Attaching a security profile to a single policy (usually the outbound one) and assuming it covers all traffic, or expecting HTTPS content to be inspected with no SSL/SSH inspection profile referenced anywhere.
Profiles are per-policy and per-direction, and several features only see what the inspection mode allows. In the GUI the profile columns are easy to scroll past, so a profile that exists in the object list is assumed to be active.
What to do instead
Audit each policy for the profiles actually referenced in the correct direction, plus the ssl-ssh-profile. Prove enforcement end-to-end with a test download/URL from a client and confirm the UTM log entry is generated for the expected policy ID; if no log appears, the profile is not on the matching policy.
Selecting 'certificate-inspection' when the requirement calls for URL filtering by full path, antivirus scanning, or application/category control inside HTTPS traffic.
Both options live in the same SSL/SSH inspection profile list, and candidates know HTTPS 'needs an SSL profile'. Certificate inspection only reads the server certificate CN/SNI, so the path and payload remain encrypted and those features have nothing to act on.
What to do instead
Use deep-inspection for content-level enforcement, deploy the FortiGate CA certificate to clients (or via GPO/MDM), and add exemptions only for pinned or legally excluded destinations. With certificate-inspection, scope the answer to certificate-based category/CN filtering. State the client-certificate dependency explicitly, because it is the usual reason 'it does not work' in the field.
Assuming TCP sessions will survive an HA failover without session pickup, or assuming the cluster primary can be selected by priority alone while 'override' is disabled.
Session pickup is a separate setting from HA being formed, and the primary election only honours configured priority when override is enabled; otherwise the first/longest-up unit stays primary. Candidates read 'HA is up and synchronised' as equivalent to 'stateful failover works'.
What to do instead
In 'config system ha', enable 'set session-pickup enable' (add 'set session-pickup-connectionless enable' if UDP/ICMP state matters) and, for deterministic primary selection, enable override and set the lowest priority on the intended primary. Validate with 'get system ha status' and a live ping/SSH through a failover.
Upgrading firmware or restoring a configuration without checking the supported upgrade path or the HA state, and without a verified configuration backup beforehand.
Firmware upgrades are only supported along specific intermediate versions, HA members must run the same build, and config formats change between branches. Candidates treat the upgrade as a single click and skip the pre-checks because they are not part of the day-to-day config workflow.
What to do instead
Read the release notes upgrade path, take 'execute backup config' (and note the encryption password), confirm all members are in sync via 'diagnose sys ha checksum show' / 'get system ha status', upgrade secondaries first or via 'execute ha manage', then confirm 'get system status' and re-verify checksums and cluster state.