FQDN Policy Order Troubleshooting
A FortiGate admin has configured a firewall policy allowing traffic from the internal network (10.0.1.0/24) to the internet (any). Users report that they cannot access a specific website (203.0.113.5). The admin runs 'diagnose firewall fqdn list' and sees that the FQDN object used in a policy above the allow policy resolves to an IP that includes 203.0.113.5. What is the MOST likely cause?
Quick Answer
The most likely cause is that the FQDN object in a higher-priority policy resolved to the IP 203.0.113.5 after the policy was created, and the FortiGate’s policy lookup uses the cached IP, matching the deny or different-NAT rule before the intended allow policy. This occurs because FortiGate processes firewall policies sequentially from top to bottom; when an FQDN-based policy is placed above the allow rule, its cached IP address can inadvertently match traffic that should be permitted, effectively blocking or misrouting it. On the Fortinet NSE 4 Network Security Professional exam, this scenario tests your understanding of FQDN policy order troubleshooting and the critical distinction between static IP objects and dynamic FQDN resolution—a common trap where admins assume FQDN policies update instantly without considering policy sequence. Remember: FQDN resolution is cached, so policy order still rules; always place specific FQDN allow rules above broader deny rules, or use a dedicated address object to avoid surprises. A useful memory tip is “Cache before cachet”—the cached IP takes precedence over the policy’s intended effect.
⚠ Common exam trap
Candidates often assume the allow policy will always match traffic to the website, but they overlook that FortiGate evaluates policies top-down and uses cached IP addresses for FQDN objects, so a higher-priority policy with a matching cached IP can intercept the traffic before the allow policy is reached.
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 FQDN object resolved to the IP after the policy was created, but the policy lookup uses the cached IP and matches before the allow policy
The FQDN object in a policy above the allow policy resolved to an IP that includes 203.0.113.5. FortiGate performs policy lookup based on cached IP addresses for FQDN objects. Since the FQDN object's cached IP now matches the destination IP of the website, traffic hits the higher-priority policy (which likely denies or otherwise blocks the traffic) before reaching the allow policy. This is why users cannot access the website despite the allow policy existing.
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 destination NAT on the allow policy is misconfigured
Why it's wrong here
NAT configuration on the allow policy would not prevent the policy from being evaluated; the issue is policy matching order.
- ✗
The FortiGate's DNS server is not resolving the FQDN correctly
Why it's wrong here
If DNS resolution were the issue, the FQDN object would not contain the IP at all, and the policy would not match.
- ✗
The antivirus profile on the allow policy is blocking the website
Why it's wrong here
Antivirus blocking would occur after the policy match; since the traffic is not reaching the allow policy, it cannot be blocked by its profiles.
- ✓
The FQDN object resolved to the IP after the policy was created, but the policy lookup uses the cached IP and matches before the allow policy
Why this is correct
Policy lookup matches the first policy where source/destination conditions are met. Since the FQDN object resolved to the destination IP, a higher-priority policy matches and the intended allow policy is never evaluated.
Visual reference
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 →
Same concept, more angles
1 more way this is tested on NSE4
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. An admin notices that a firewall policy allowing inbound HTTPS to a server is not matching traffic. The policy has source set to 'all', destination to the server's IP, and service to HTTPS. The admin checks the policy list and sees that policy ID 1 matches the traffic. What is the MOST likely reason the intended policy (ID 10) is not matching?
hard- ✓ A.Policy ID 1 has a higher priority and matches before policy ID 10
- B.The firewall policy is disabled
- C.The service object for HTTPS is misconfigured in policy ID 10
- D.The destination address is incorrect in policy ID 10
Why A: Policy ID 1 has a higher priority because FortiGate evaluates firewall policies in sequential order from top to bottom. When policy ID 1 matches the traffic (e.g., it also allows HTTPS to the same destination), the traffic is processed by policy ID 1 and never reaches policy ID 10. This is the most likely reason the intended policy is not matching.
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.