NSE4 Firewall Policies and NAT Practice Question
A network administrator creates a firewall policy allowing HTTP traffic from the internal network to a web server in the DMZ. Users report that they cannot access the web server. The administrator runs 'diagnose firewall iprope list' and sees the policy is present. What is the MOST likely cause of the issue?
⚠ Common exam trap
Many candidates assume 'policy is present' means it is working, but FortiGate's policy order (lowest ID first) means a lower-ID deny policy can override a higher-ID allow policy even if both match the same traffic.
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
✓
A deny policy with a lower policy ID is matching the traffic before the allow policy
The 'diagnose firewall iprope list' command confirms the allow policy exists in the FortiGate's kernel policy list, meaning it is present and enabled. However, FortiGate evaluates policies in sequential order based on policy ID (lowest first), so a deny policy with a lower ID that matches the same traffic (e.g., from internal to DMZ) will be hit first, blocking the HTTP request before the allow policy can be evaluated. This is the most likely cause because the policy is present but not being matched due to ordering.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
A deny policy with a lower policy ID is matching the traffic before the allow policy
Why this is correct
In FortiGate, policy matching uses a first-match model: the firewall processes rules in ascending policy ID order and stops at the first rule whose source, destination, and service match the session. If a deny policy with a lower ID (i.e., positioned earlier in the policy list) matches the same HTTP traffic as the intended allow policy, that deny will drop the packets and the allow policy will never be reached. This shadowing behavior is the most probable cause, and it can be confirmed by placing the allow rule above the deny or by comparing policy IDs in the `get firewall policy` output.
- ✗
The firewall policy has an incorrect source interface
Why it's wrong here
An incorrect source interface on the allow policy would prevent it from matching traffic that arrives on a different interface, but it would not explain why an explicitly configured lower-ID deny policy is blocking the session. For a policy-based firewall, the source interface is part of the matching criteria, and a mismatched interface causes the rule to be skipped, resulting in zero hits on that rule. In contrast, the correct diagnosis is rule ordering, because the deny policy is actively intercepting the session before the allow rule is ever evaluated, which would produce a 'deny' log entry with the lower policy ID.
- ✗
The policy is disabled
Why it's wrong here
A disabled firewall policy is still present in the configuration but is not loaded into the active rule set, so it can never match or permit traffic; if the allow policy were disabled, HTTP sessions would simply fall through to the implicit deny at the end of the policy list, not to a specific lower-ID deny entry. The administrator's scenario describes traffic being blocked, and a disabled rule would not generate a 'denied by policy' event with that rule's ID because it is not evaluated. Since the question identifies shadowing as the root cause, a disabled policy, while possible, is a less direct explanation and would require checking the `status` flag in the policy configuration.
- ✗
The web server is not responding to HTTP requests
Why it's wrong here
A web server that is not responding is a host-side problem that would occur after the firewall has already allowed the traffic, so it cannot explain why the firewall policy itself is dropping the session. With an HTTP request to an unreachable server, the client typically experiences a timeout or TCP RST, whereas a deny policy creates an immediate drop with a 'denied by policy' entry in the forwarding logs. The scenario is focused on a firewall-policy configguration issue, so the correct answer is that the deny policy with a lower ID is matching first, not any server unavailability.
Go deeper
Related to this question
About these practice questions
One of 282 original NSE4 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.