NSE4 High Availability and Diagnostics Practice Question
An administrator executes 'diagnose debug flow' for a specific session and sees the output: 'id=20085 trace_id=10 func=print_pkt_detail line=5567 msg="vd-root:0 received packet via port1".' Later, the trace shows 'msg="Deny by policy"'. What is the most likely next step the administrator should take?
⚠ Common exam trap
NSE4 often tests debug flow message interpretation — candidates see 'Deny by policy' and jump to routing or session issues instead of recognizing it as a firewall policy match failure.
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
✓
Review the firewall policies that apply to the traffic and modify as needed
The debug flow output shows the packet was received on port1 and then hit 'Deny by policy', meaning a firewall policy explicitly blocked the traffic. The next logical step is to review the firewall policies that match the traffic's source, destination, service, and incoming interface, and adjust them to permit the intended flow.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Check the routing table for the destination
Why it's wrong here
The `diagnose debug flow` output explicitly showed the packet was received and then denied by policy; a routing-table lookup happens before policy evaluation, so if a route were missing the packet would have been dropped with a 'no route' message, not 'Deny by policy'. Verifying the routing table would only be relevant if the flow output indicated a routing failure or an implicit drop due to no route. Since the log already identifies policy as the enforcing component, investigating routing is irrelevant to this specific denial.
- ✓
Review the firewall policies that apply to the traffic and modify as needed
Why this is correct
The debug flow output's 'Deny by policy' verdict means the FortiGate's firewall policy engine evaluated the packet against the configured policy set and explicitly rejected it, typically due to the absence of a matching permit policy, a matching explicit deny policy, or a policy that disallows the tuple (source, destination, service, user, etc.). Because the packet is denied before session creation, the administrator should inspect the policy list with `diagnose firewall policy list` or via the GUI, and either adjust the existing policy's matching criteria/action or create a new permit policy that allows the legitimate traffic. Correctly aligning the policy to the intended traffic flow is the direct and standard fix, avoiding unnecessary service disruption.
- ✗
Restart the FortiGate to clear session table
Why it's wrong here
Restarting the FortiGate to clear the session table is a blunt, non-surgical action that does not affect the policy definition, which is stored in configuration and reloaded unchanged after the reboot. The debug flow output shows a policy-based denial, not a stale or corrupted session entry; therefore clearing the session table would not change the outcome and would cause downtime for all traffic traversing the device. Only policies or policy objects (addresses, services, users) can be modified to resolve the denial, making a reboot both ineffective and unnecessarily disruptive.
- ✗
Enable session helper for the protocol
Why it's wrong here
Session helpers are protocol-agnostic kernel modules that handle ALG (Application Layer Gateway) tasks such as NAT64, RTSP, SIP, or FTP data-channel negotiation, and they only come into play after a session is allowed and created. A 'Deny by policy' event occurs during the initial policy lookup, before any session is established; thus enabling a session helper cannot override or bypass a firewall policy rejection. The debug flow would show a session-helper issue only if the packet was permitted but the ALG failed to parse payloads or open companion sessions, which is not the case here.
Go deeper
Related to this question
About these practice questions
Courseiva writes every NSE4 question from scratch — 773 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 →
Same concept, more angles
4 more ways 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. A FortiGate administrator runs 'diagnose debug flow' with a filter for a specific source IP. The output shows 'no policy matched' for the traffic. The administrator verifies that a firewall policy exists with that source IP. What is the most likely reason for the 'no policy matched' message?
hard- A.The firewall policy is disabled
- B.The debug flow filter is not configured correctly
- C.The source IP is not in the routing table
- ✓ D.The traffic is being blocked by an implicit deny or a different policy before reaching the expected policy
Why D: Debug flow may show 'no policy matched' when traffic hits an implicit deny or a different policy before reaching the expected policy, such as due to policy order where an earlier policy with a broader match blocks it, or inter-VDOM routing issues. Option B is incorrect because the debug flow filter is working correctly—it matches the source IP; the issue is that no applicable policy is found for that traffic.
Variation 2. A FortiGate administrator runs 'diagnose debug flow' and sees the output 'FW-6: packet is allowed by policy' but the packet is still dropped. What additional debug information should the administrator check to determine why the packet is dropped after being allowed?
hard- A.Check the traffic log for the session
- ✓ B.Enable 'diagnose debug flow show function-name' to see more detailed stages
- C.Check the session table for the packet
- D.Run 'diagnose sniffer packet' to capture the packet
Why B: After policy lookup, further processing like security profiles, NAT, or routing may drop the packet. The 'function-name' parameter in debug flow shows deeper inspection stages.
Variation 3. An administrator runs 'diagnose debug flow' and sees the output 'no matching policy'. What does this indicate?
medium- A.The packet is being processed by a policy with the correct source/destination
- ✓ B.There is no firewall policy that allows the traffic from the source to the destination
- C.The packet was dropped due to an antivirus signature match
- D.The packet is being routed through a blackhole route
Why B: The debug flow trace shows packets flowing through the firewall policy evaluation. 'No matching policy' means the packet did not match any firewall policy.
Variation 4. An administrator runs 'diagnose debug flow' for a specific policy and sees the following output: id=20085 trace_id=10 func=vf_ip_route_in msg='No matching interface to route packet' What does this indicate?
hard- A.The packet is being blocked by a firewall policy
- B.The source interface is down
- ✓ C.The destination IP address has no matching route in the routing table
- D.The session table is full
Why C: The trace indicates that FortiGate cannot find a route to forward the packet, meaning the destination is unreachable.
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Fortinet exam blueprint
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.