NSE4 Firewall Policies and NAT Practice Question
A FortiGate administrator has configured a firewall policy allowing HTTP traffic from the internal network (10.0.1.0/24) to the DMZ server (192.168.1.10). The policy is placed after a deny-all policy that blocks traffic from internal to DMZ. Even though the allow policy is more specific, traffic is still being denied. What is the most likely cause?
⚠ Common exam trap
The trap here is that candidates mistakenly believe FortiGate uses a 'best-match' or 'most-specific' logic like routing tables, when in fact it uses strict first-match sequential evaluation, making policy order critical.
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 deny-all policy is placed above the allow policy in the policy list
FortiGate firewall policies are evaluated sequentially from top to bottom. The first matching policy is applied, and subsequent policies are ignored. Since the deny-all policy is placed above the more specific allow policy, traffic from 10.0.1.0/24 to 192.168.1.10 matches the deny-all first and is dropped, never reaching the allow 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 deny-all policy has a higher policy ID than the allow policy
Why it's wrong here
Policy ID is not a precedence attribute in FortiOS. Firewall policies are evaluated strictly in the order they appear in the policy list, from top to bottom, regardless of their numeric IDs. A deny-all policy with a higher ID could match only if it is physically placed above the allow policy; the ID alone has no effect on evaluation order.
- ✗
The allow policy is configured with the wrong source interface
Why it's wrong here
If the allow policy's source interface is set incorrectly, traffic arriving on the expected interface simply will not match that policy, so the FortiGate will continue scanning subsequent policies. That can lead to a lower deny-all matching, but the root cause is a configuration error on the allow policy, not a property of the deny-all policy itself. The symptom described—deny-all blocking—would still only happen if no earlier policy matches, not because deny-all is above.
- ✗
The allow policy uses a schedule that is not active at the current time
Why it's wrong here
A schedule that is inactive causes the firewall to skip the allow policy entirely, and the packet falls through to the next matching rule. If the deny-all is placed below the allow, the inactive schedule is what makes the deny-all match, so the problem would be a time-based configuration issue, not the order of rules. The deny-all policy itself is not misordered; it is simply the first match remaining.
- ✓
The deny-all policy is placed above the allow policy in the policy list
Why this is correct
FortiOS performs first-match evaluation, checking rules top-down and enforcing the first rule whose all conditions (source, destination, service, schedule, etc.) are satisfied. If a broad deny-all is positioned above the specific allow policy, every packet that would otherwise match the allow rule hits the deny-all first and is dropped. That is the classic misordering mistake, and it cannot be compensated for by policy IDs or other attributes.
Go deeper
Related to this question
About these practice questions
Courseiva writes every NSE4 question from scratch — 282 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.