NSE4 System and Network Administration Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Check firewall policies, then check NAT rules, then check routing, then perform packet capture, then review logs

  Why this is correct

  This sequence mirrors the FortiOS session creation order: traffic must match a firewall policy first, and if no policy permits it, the session is denied before any NAT or routing decision is consulted. After a policy match, Destination NAT (VIP) and Source NAT are evaluated via the NAT table, followed by routing to choose the egress interface and next hop. Only after those configuration layers are verified does a packet capture make sense, because it will show traffic that already passed or failed those checks. Reviewing traffic logs last lets you correlate the captured packets with log records, confirming whether the session was allowed, denied, or stuck due to NAT or routing misconfiguration.

• ✗

  Check routing, then check NAT rules, then check firewall policies, then review logs, then perform packet capture

  Why it's wrong here

  Starting with routing and NAT before firewall policies is inefficient because the FortiGate evaluates policy as the first logical gate; if traffic is denied by a policy, no route or NAT rule can rescue it, and you may spend time analyzing routing tables for packets that are never forwarded. Additionally, placing review logs before packet capture inverts the correct forensic flow: logs often only show high-level results (e.g., 'denied by policy'), while a packet capture provides the raw packets needed to understand why the session failed, such as NAT port exhaustion or asymmetric routing. A proper diagnosis should eliminate the most common policy issues first, then verify NAT and routing, because both NAT and routing assume a policy already allowed the session.

• ✗

  Review logs, then check firewall policies, then check NAT rules, then check routing, then perform packet capture

  Why it's wrong here

  Beginning with logs is misleading because a log entry only tells you that a session was dropped or accepted, not which configuration object caused the action—for example, a log might show 'action=deny' but you still need to check the firewall policy to see which policy did the denial and why. It also risks anchoring you to a single log record without context; you might miss that the traffic was never logged because it was dropped before the policy check, such as on the incoming interface due to IPS or route lookup failure. Furthermore, saving packet capture for last means you may have already committed to a hypothesis based on logs, whereas capturing earlier—after policy, NAT, and routing checks—would give you decisive packet-level evidence to confirm the actual path.

• ✗

  Check NAT rules, then perform packet capture, then check firewall policies, then check routing, then review logs

  Why it's wrong here

  Checking NAT rules before firewall policies is inherently flawed because a FortiGate does not even consult the NAT table until the session has matched a policy; so a NAT rule you diagnose may be irrelevant if the traffic is denied by policy or falls into an implicit deny. Performing packet capture immediately after NAT and before policy checks will capture traffic indiscriminately, including packets that are about to be dropped by policy, which wastes analysis time and can hide the real root cause behind irrelevant packets. Even worse, this order places routing last, yet routing is critical for the return path and for determining which interface the packet egresses; without checking routing, you might capture ingress packets and think the problem is NAT when it is actually a missing route. A correct sequence must follow the dataplane's actual evaluation order: policy, NAT, routing, then capture, with logs used only for final confirmation.

Go deeper

Related to this question