NSE4 Firewall Policies and NAT Practice Question
An administrator is configuring policy-based routing (PBR) on a FortiGate to route traffic from a specific subnet (172.16.1.0/24) through a different internet connection (wan2) instead of the default route via wan1. The administrator has created a PBR rule matching source 172.16.1.0/24 and set the gateway to the next-hop IP on wan2. The traffic is still using wan1. Which THREE of the following could be causing the issue? (Choose three.)
⚠ Common exam trap
The trap here is that candidates often overlook the gateway reachability requirement for PBR, assuming any IP can be used as a next-hop, or they confuse PBR priority with static route administrative distance.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The PBR rule's gateway is not reachable from the FortiGate
PBR requires the specified next-hop gateway to be reachable via a directly connected route or a static route; if the gateway IP on wan2 is not reachable (e.g., due to a missing ARP entry or link failure), the FortiGate will fall back to the routing table and use the default route via wan1. The FortiGate performs a reachability check on the PBR gateway before applying the rule.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
The PBR rule's gateway is not reachable from the FortiGate
Why this is correct
For a PBR rule to be used, the FortiGate must be able to reach the configured gateway (next-hop). If the gateway is on a directly connected network, the FortiGate must resolve its MAC address via ARP; if the gateway is on a remote network, it must have a valid route to that gateway. When the next-hop is unreachable, the PBR rule is marked as inactive and is skipped during evaluation, causing the traffic to fall through to the normal routing table lookup. Even if a default static route exists, an unreachable PBR next-hop will never be used, so this directly explains why the rule is not matching.
- ✗
The PBR rule's priority is set too high (e.g., 100) and a static route with lower priority is used instead
Why it's wrong here
PBR rules are evaluated before the routing table lookup, and the priority (or sequence number) among PBR rules only determines the order in which those rules are tested. A lower priority number (e.g., 1) is higher priority than a higher number (e.g., 100), but this ordering does not cause the routing table to override a PBR rule. Static routes are only consulted when no enabled PBR rule matches the traffic. Therefore, a static route with a 'lower priority' (or higher administrative distance) cannot override an existing PBR rule, so this is not a valid reason for the traffic not being policy-routed.
- ✓
The PBR rule is applied to the wrong incoming interface
Why this is correct
In FortiOS, each PBR rule explicitly specifies an incoming interface, and the rule is evaluated only for traffic that enters the FortiGate on that exact interface. If the traffic arrives on a different interface—for example, the rule is applied to 'internal' but the client is plugged into 'internal2'—the rule will not match and the traffic will be processed using the regular routing table. This is a common misconfiguration when multiple internal interfaces exist or when traffic is being received over a subinterface or VLAN. Verifying the incoming interface against the actual ingress port is a critical first step in PBR troubleshooting.
- ✓
The PBR rule is disabled
Why this is correct
A PBR rule that is disabled in the FortiGate configuration is completely ignored during evaluation and does not participate in any traffic matching. This can happen if the administrator temporarily disabled the rule to test a routing change and then forgot to re-enable it, or if the rule was created in a disabled state during initial configuration. Even if all other parameters (source, destination, interface, gateway) are correct, a disabled rule will never be applied. Checking the rule's status in both the GUI and CLI (via 'show policy-route' or 'get router policy') is essential to ensure it is enabled.
- ✗
The PBR rule's destination is set to 'all' but the traffic's destination is not covered
Why it's wrong here
When the destination in a PBR rule is set to 'all', that acts as a wildcard that matches any destination IP address—it is equivalent to 0.0.0.0/0 and covers the entire IPv4 address space. Therefore, if the rule's destination is 'all', it cannot be the cause of the traffic not matching; the traffic's destination will always be included. The only way a destination setting could prevent a match is if it specifies a specific subnet or address that does not include the traffic's destination. Since the administrator set it to 'all', the destination field is not the problem, so this option does not explain the observed behavior.
Visual reference
Go deeper
Related to this question
About these practice questions
This NSE4 question is part of Courseiva's 773-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This NSE4 practice question is part of Courseiva's free Fortinet certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the NSE4 exam.