NSE 8 common mistakes
NSE 8 · Understand the traps and how to avoid them.
Designing the topology around FortiGate interfaces one-for-one with physical links, then discovering the proposed segmentation cannot survive a single link or device failure.
Candidates who normally work on small deployments think in terms of point-to-point links and forget that the design question is about resilience under failure; they draw a working network, not a redundant one, and never test the design against a lost uplink, a lost HA member, or a lost ISP.
What to do instead
Before writing the design, list the failure scenarios explicitly (single WAN link loss, single FortiGate loss, single switch loss, single ISP loss) and trace traffic for each. Confirm each scenario has a documented path, and state which sessions survive and which are reset. Include the expected convergence behaviour and the failover mechanism (FGCP, SD-WAN, BGP, or dynamic routing) in the design narrative.
Treating the design question as a configuration question and answering with CLI snippets instead of a written architecture with requirements, constraints, and trade-offs.
Hands-on engineers default to showing what they can configure. The design domain asks for justification: why this segmentation, why this inspection point, why this HA mode. Configuration detail without the reasoning behind it scores poorly even when the commands are correct.
What to do instead
Structure the answer as requirements, proposed design, alternatives considered, and risks. For each major choice, write one sentence of justification tied to a stated requirement. Keep CLI to the minimum needed to make the design concrete, and put the reasoning in prose. Practise writing a one-page design summary before touching configuration.
Ignoring asymmetric routing when placing multiple inspection points, then proposing a design where return traffic bypasses the FortiGate that inspected the forward flow.
Complex networks often have more than one path between zones. Candidates add a firewall at each boundary without checking whether both directions of a flow traverse the same device, and the resulting design either drops legitimate sessions or silently skips inspection.
What to do instead
Map every zone-to-zone flow and mark the forward and return path on the diagram. Where paths diverge, either force symmetry with routing policy or design for asymmetric handling (session helpers off, expected behaviour documented). Call out in the design which flows are stateful-inspected and which are not, and why that is acceptable.
Proposing a full-mesh or hub-and-spoke overlay without sizing the encryption and tunnel count against the platform model, so the design is technically valid but exceeds the hardware.
Design questions reward completeness, and candidates add IPsec between every site because it looks secure. They do not check tunnel limits, throughput with encryption enabled, or the number of security profiles applied per tunnel, so the design cannot be built on the proposed hardware.
What to do instead
For each site, tabulate tunnel count, expected throughput, and the profiles applied. Compare against the datasheet figures for the chosen model with the relevant features enabled, and leave headroom for growth. If the numbers do not fit, change the topology (partial mesh, regional hubs) rather than assuming the hardware will cope.
Copying a working production configuration into the answer without adapting object names, addresses, and policy order to the scenario given in the question.
Candidates reuse fragments from memory or from their own environment. The scenario has different subnets, different interface roles, and different policy intent, so the pasted configuration references objects that do not exist or applies the wrong profile to the wrong traffic.
What to do instead
Read the scenario and write down the address plan and interface roles first. Build objects from that plan, then write policies in the order the scenario requires. After writing, re-read each policy and confirm source, destination, service, and profile match the stated intent. Treat any leftover name from your own environment as a signal to re-check.
Getting policy order wrong so a broad permit rule above a specific deny rule allows traffic the design intended to block.
FortiGate evaluates policies top-down and stops at the first match. Candidates add the new specific rule at the bottom or insert a general internet-access rule above the segmentation rules, and the first-match behaviour silently overrides the intent.
What to do instead
Place deny and specific rules above broad permit rules, and keep a consistent ordering convention (most specific to least specific). After editing, walk the policy list top-down for a sample flow and confirm which rule matches first. Where possible, use explicit deny rules with logging so a misordering is visible in the logs rather than silent.
Configuring NAT and routing independently, so the design has the right NAT rule and the right route but return traffic still fails because the two do not agree on the egress interface or address.
NAT and routing are configured in different parts of the GUI and candidates treat them as separate tasks. A policy-based NAT rule referencing the wrong outgoing interface, or a route pointing somewhere other than the NAT address, produces a configuration that looks complete but cannot pass a round trip.
What to do instead
For each flow, state the ingress interface, the policy, the NAT action, the egress interface, and the return route as one chain. Verify the chain end to end rather than each element in isolation. Use the routing monitor and session table to confirm the egress interface chosen matches the interface referenced in the NAT configuration.
Building an HA pair with mismatched configuration or licensing, then assuming failover will work because both units show as synchronised.
Candidates configure the primary and rely on automatic sync, without checking that the secondary has the same firmware, the same licence entitlements, and the same interface and routing configuration. Some settings are not synchronised, and a failover test is never run.
What to do instead
Before declaring the pair complete, compare firmware, licence, and the settings that are not synchronised (for example HA-specific interface configuration and some routing). Then run an actual failover: pull the primary, confirm session behaviour, confirm the secondary takes over the addresses and routes, and confirm traffic resumes. Document what was tested.
Debugging by turning off security profiles or inspection until traffic flows, instead of isolating the specific component that is dropping the session.
Under time pressure, disabling the profile restores connectivity and the candidate moves on. The root cause is never found, and in a troubleshooting scenario the answer then describes a workaround rather than a diagnosis, which does not demonstrate the required skill.
What to do instead
Use the tools in order: session table to confirm the session exists and its state, debug flow filtered to the specific source and destination, and log entries for the policy that matched. Change one variable at a time. State the root cause explicitly in the answer, and only then describe the fix.
Reading a packet capture or debug output and stopping at the first anomaly instead of following the flow through all stages to the actual drop point.
Complex networks have several plausible anomalies (a retransmission, a reset, an unexpected route). Candidates latch onto the first one and write a diagnosis around it, without confirming that the flow reaches the FortiGate, matches the intended policy, is inspected, and is forwarded.
What to do instead
Trace the flow in fixed stages: arrives at interface, matches policy, passes inspection, is NATed, is routed, leaves interface, return path exists. For each stage, state the evidence that it succeeded or the evidence that it failed. Only conclude once the failure stage is identified with evidence, and say which tool provided that evidence.