Fortinet FCSS NST common mistakes
Fortinet FCSS NST · Understand the traps and how to avoid them.
When a question describes asymmetric routing or multiple paths between two FortiGates, the candidate answers from the perspective of a single firewall and ignores that stateful inspection requires both directions of the flow to traverse the same device.
Most hands-on practice uses a simple perimeter topology, so session state, TCP sequence checking and anti-replay are learned as abstract facts rather than as constraints on the design. The candidate reads the topology but does not mentally trace the return path.
What to do instead
Before answering any topology question, explicitly draw the forward and return path for one sample flow and mark where each FortiGate sees it. Where paths diverge, evaluate the options that restore symmetry: session helpers such as auxiliary-session, asymmetric routing handling, VDOM or VRF separation, or policy routing that pins the return traffic. Reject any option that only fixes the forward direction.
The candidate treats VDOMs as a complete segmentation solution and forgets that inter-VDOM links, global resources and shared interfaces still create reachability and policy-ordering questions.
VDOMs are taught as 'virtual firewalls', which leads candidates to assume full isolation. Exam items that hinge on inter-VDOM-link policy direction, management VDOM placement, or global versus per-VDOM object scope then look ambiguous.
What to do instead
Memorise the concrete mechanics: an inter-VDOM link is a pair of interfaces, one in each VDOM, and traffic between them is still filtered by policies in each VDOM in the direction of egress. Know which objects are global (e.g. global address and service objects, global policies) versus per-VDOM, and where the management VDOM sits. For each design option, ask which VDOM's policy inspects the packet and in which direction.
In routing questions the candidate selects an answer based on administrative distance alone and ignores that FortiOS selects routes by longest prefix match first, and that policy routes and SD-WAN rules are evaluated before the routing table lookup.
Candidates carry over a distance-first mental model from other vendors, or study route selection as a list of tie-breakers without the ordering between policy routing, SD-WAN service rules and the FIB lookup.
What to do instead
Reconstruct the actual decision order for a packet: policy route match, then SD-WAN rule match, then longest-prefix match in the routing table, then administrative distance and metric as tie-breakers within equal prefixes. Practise with a small lab that has overlapping static, connected and OSPF routes plus one policy route, and predict the egress interface before checking the session list.
The candidate configures or evaluates ECMP and SD-WAN without accounting for how sessions are pinned to a member and what happens to existing sessions when a member fails or a health check flaps.
SD-WAN is often studied as a list of SLA health-check settings. The session-level consequences (sessions staying on the original member, behaviour on member failure, hold-down timers) are less visible in a GUI walkthrough and are exactly what scenario items probe.
What to do instead
Learn the session-pinning behaviour explicitly: a session keeps its egress member unless the member becomes unavailable, and SD-WAN rules with SLA targets influence new sessions only. Study how health-check failure marks a member inactive, how hold-down and restore timers affect flapping, and how symmetric return is preserved. Then answer scenario items by asking 'what happens to the sessions already established' before choosing.
The candidate applies a security profile (web filter, antivirus, IPS, application control) and assumes it acts on all traffic, forgetting profile direction, SSL inspection prerequisites, and proxy versus flow inspection modes.
Profiles are usually demonstrated on outbound HTTP with a single policy. Items that place the profile on an inbound policy, behind a policy with no SSL inspection, or in a flow-mode profile behave differently and the candidate does not check those preconditions.
What to do instead
For every profile question, first establish three facts: the policy direction, whether traffic is encrypted and whether a certificate-inspection profile is attached, and whether the FortiGate is in proxy or flow inspection mode. Know which profiles are proxy-only or behave differently in flow mode, and that certificate inspection (CN-only) versus deep inspection changes what can be matched. Answer only after those three facts are pinned down.
The candidate confuses certificate inspection with full SSL deep inspection, and assumes URL filtering, file scanning and application identification work identically under both.
Both are configured on the same policy and both involve certificates, so the distinction blurs. The candidate does not recall that certificate inspection exposes only the server certificate name and cannot decrypt payload, which limits content-based profiles.
What to do instead
Memorise the split: certificate inspection reads the certificate to extract the CN/SNI for category and SNI-based matching but does not decrypt; deep inspection terminates TLS with a FortiGate CA certificate and enables full content inspection. Learn the operational prerequisites for deep inspection (CA distribution to clients, exclusions for pinned or sensitive categories, exemptions for certificate-pinned applications) and use them to eliminate options that promise payload inspection without decryption.
In IPsec items the candidate picks a phase 1 or phase 2 setting that looks reasonable but is not symmetric with the peer, such as mismatched proposal lists, different PFS settings, or a selector mismatch.
The candidate studies IKE and IPsec as separate configuration pages and does not build the habit of checking both ends. Many items only describe one side, so the candidate answers for that side alone rather than deriving what the peer must be configured with.
What to do instead
For any tunnel question, write out the required peer values for each parameter: IKE version, authentication method and pre-shared key or certificate, encryption and hash proposals, DH group, and for phase 2 the selectors, PFS and replay window. Remember that a proposal list must have at least one common entry, and that PFS must match or the tunnel fails at quick mode. Use that checklist to test the proposed change against the described peer.
The candidate treats dial-up and redundant IPsec designs as if all tunnels were static, and misses how dynamic peers, tunnel aggregation and route injection change failover behaviour.
Static site-to-site tunnels dominate study material. Dial-up server configuration, IKEv2 dynamic peers, and ADVPN shortcuts are learned as feature names rather than as mechanisms with specific failure and route behaviour.
What to do instead
Learn the concrete mechanics of each: how a dial-up server accepts dynamic peers and what identifies them, how IKEv2 configuration payloads assign addresses, how ADVPN advertises shortcuts via BGP or OSPF and when a shortcut is torn down, and how dead-peer detection and DPD settings drive failover. For each scenario, identify which tunnel carries the traffic after failover and whether routing or the tunnel itself makes that happen.
The candidate answers authentication questions by naming a method (LDAP, RADIUS, SAML, local, certificate) without checking where the user is authenticated in the flow, which groups are returned, and how the identity is applied to policy.
Authentication is studied as a list of server types. The path from user credential to group membership to policy match, including the role of FSSO collectors and the difference between explicit and transparent authentication, is what the scenario items actually test.
What to do instead
Trace the identity path for each method: who receives the credential, which server returns the group, how the FortiGate maps that to a user group, and which policy matches on the group. Know the difference between FSSO agent, collector agent and polling modes, and that group membership must be resolvable on the FortiGate for policy matching. Eliminate options that name a valid method but cannot deliver the required group or apply to the described traffic type.
In high availability items the candidate describes HA as simple active-passive redundancy and ignores session synchronisation scope, override and priority behaviour, and what happens to sessions that were not synchronised.
HA is often learned as 'two boxes, one primary'. The details that decide exam answers - which sessions are synchronised, the effect of override on failback, link monitoring and failover triggers, and HA reserved management interfaces - are less practised.
What to do instead
Build a mental HA checklist: mode (active-passive versus active-active), sync scope (which protocols and whether asymmetric or non-TCP sessions are synchronised), priority and override determining primary selection and failback, monitored interfaces and their failover effect, and heartbeat and gratuitous ARP behaviour on failover. For each scenario, state which unit becomes primary and which existing sessions survive, then choose the option consistent with that.