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?
FortiGate evaluates policies sequentially from top to bottom. If a deny policy appears earlier in the list, it will match and block the traffic before reaching the allow policy.
Why this answer
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.
Exam trap
The trap here is that 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.
How to eliminate wrong answers
Option B is wrong because an incorrect source interface would cause the policy not to match at all, but the 'diagnose firewall iprope list' output would not show the policy as present for that traffic flow; the administrator would see no matching entry. Option C is wrong because a disabled policy would not appear in the 'diagnose firewall iprope list' output at all, yet the administrator sees it present. Option D is wrong because the web server not responding would result in a timeout or connection reset, but the firewall would still allow the traffic (the policy would match), and the issue would be reported differently; the 'diagnose firewall iprope list' check would not be the first troubleshooting step for a server-side problem.