Fortinet NSE 6 common mistakes
Fortinet NSE 6 · Understand the traps and how to avoid them.
Treating the FortiGate security profile order as arbitrary and enabling antivirus, IPS, web filter, and SSL inspection in whatever sequence the GUI presents them, then failing scenario items that ask which profile inspects traffic first.
Candidates memorize profile names from documentation but never reason about the actual packet flow through the proxy, so they cannot predict how one profile's action (block, monitor, quarantine) changes what downstream profiles see.
What to do instead
Walk the proxy inspection pipeline explicitly for each scenario: TLS decryption where required, then antivirus, then IPS, then application control and web filtering, and note where a block short-circuits the rest. Rebuild the flow from the FortiOS documentation on proxy vs flow-based inspection until you can state it without notes.
Configuring a firewall policy with NAT enabled but forgetting that the destination interface determines which NAT pool applies, then missing questions about why return traffic fails or why the wrong source IP appears at the server.
NAT is learned as a checkbox rather than as a routing and policy-matching decision, so candidates do not connect the policy's incoming/outgoing interface pair to the NAT behavior and the associated route lookup.
What to do instead
For every NAT scenario, write out the five-tuple, the matched policy, the outgoing interface, and the resulting translated address before answering. Practice with central NAT versus policy NAT so you can state which object type each uses and when a VIP or IP pool is required.
Assuming a static route alone makes traffic reachable and ignoring policy routes, SD-WAN rules, and reverse path forwarding checks when diagnosing why a packet is dropped.
Candidates study routing and firewall policy as separate chapters, so under exam pressure they pick the route table answer when the actual drop is an RPF failure or a policy route overriding the lookup.
What to do instead
Memorize the FortiGate packet-flow order of operations (ingress, RPF, policy route, destination lookup, policy match, egress) and use it as a checklist. For each practice scenario, name the exact step where the packet dies and the CLI command (such as debug flow with the relevant filters) that would confirm it.
Reading a FortiAnalyzer or FortiSIEM event log and reporting the raw log field as the finding instead of correlating it with adjacent events to identify the actual incident.
Security operations content rewards tool familiarity, so candidates learn where logs live but not how to build a timeline, which leads to answers that describe a single log line rather than the attack behavior.
What to do instead
Practice writing a three-line incident narrative from a small log excerpt: what happened first, what the attacker did next, and what evidence confirms the outcome. Learn the difference between a detection, an alert, and an incident, and be able to say which log source (traffic, IPS, authentication, endpoint) supports each conclusion.
Confusing an automation stitch with a playbook and selecting the wrong trigger or action type when asked how to automatically quarantine a compromised endpoint.
Both features live in the same FortiGate and FortiSOAR-adjacent space, and candidates memorize feature names without mapping each to its trigger mechanism, execution location, and typical response action.
What to do instead
Build a comparison table of stitch versus playbook: where it runs, what triggers it, what actions it can take, and how it is audited. Then design one end-to-end response (compromised host to quarantine to notification) and identify which component performs each step.
Answering incident-response sequencing questions by jumping straight to containment and eradication without establishing scope or preserving evidence.
Candidates default to the most dramatic action because it feels decisive, and they have not internalized that the exam tests a defined lifecycle with preparation, identification, containment, eradication, recovery, and lessons learned.
What to do instead
Memorize the lifecycle phases and, for each scenario, state the phase the question is asking about before choosing an action. Practice justifying why evidence collection or scoping precedes containment in the specific case, and note where containment can run in parallel with identification.
Treating a public cloud security group as equivalent to a FortiGate firewall policy and missing that stateful inspection, application control, and TLS inspection may not exist at that layer.
Candidates carry on-premises mental models into cloud questions, assuming the same depth of inspection is available natively, so they choose answers that overstate what the cloud provider's controls do.
What to do instead
For each cloud scenario, separate native controls (security groups, network ACLs, cloud WAF) from the FortiGate VM's role, and state which layer enforces stateful policy, which enforces application awareness, and where traffic must be steered for inspection. Practice describing the routing change needed to insert the firewall VM into the path.
Deploying a FortiGate VM in the cloud without accounting for the cloud fabric's source NAT, health checks, or asymmetric routing, then failing questions about why the HA pair or load balancer behaves unexpectedly.
Cloud networking hides the underlying translation and probe behavior, so candidates configure the FortiGate as they would on-premises and cannot explain why sessions break or failover does not occur.
What to do instead
Learn the specific cloud constructs that touch firewall traffic: load balancer health probes, floating IPs, and provider NAT. For each, write how the FortiGate sees the source address and which configuration (for example, preserving the original source or adjusting probe expectations) makes the design work.
Mixing up IKE phase 1 and phase 2 parameters when troubleshooting an IPsec tunnel that is down, changing proposals at random rather than isolating which phase fails.
Both phases have proposals, lifetimes, and selectors, and candidates memorize the parameter names without learning which negotiation step each belongs to, so they cannot read the debug output.
What to do instead
Map every parameter to its phase and to the debug line that reveals a mismatch. Practice reading IKE debug output to identify whether the failure is proposal mismatch, pre-shared key, peer ID, or traffic selector, and state the single configuration change that resolves each.
Designing SD-WAN rules by intent words (best quality, lowest cost) without verifying that the referenced health checks, SLA targets, and member interfaces exist and are consistent.
SD-WAN is taught as a policy concept, so candidates pick the rule that sounds right and overlook that a rule referencing a missing SLA target or an interface not in the zone silently fails to steer traffic.
What to do instead
For each SD-WAN scenario, list the members, the health-check targets, the SLA thresholds, and the rule priority, and confirm each rule's referenced objects exist. Practice predicting which member is chosen when two rules overlap and when an SLA is violated, including the behavior when no member meets the SLA.