Troubleshooting and Diagnostics →hardMultiple ChoiceObjective-mapped

NSE7 Troubleshooting and Diagnostics Practice Question

Exhibit

Refer to the exhibit.

config firewall policy
    edit 1
        set name "Allow-Web"
        set srcintf "port1"
        set dstintf "port2"
        set srcaddr "10.0.1.0/24"
        set dstaddr "10.0.2.100"
        set action accept
        set schedule "always"
        set service "HTTP"
        set logtraffic all
    next
end

diag debug flow show function-name show-verbose

--- flow debug output ---
proton_state=0, reason=session-denied
id=20085 trace_id=155 func=print_pkt_detail line=4945 msg="vd-root:0 received a packet from port1: 10.0.1.5:45231 -> 10.0.2.100:80, proto 6."
id=20085 trace_id=155 func=resolve_ip_tuple line=4125 msg="Find an existing session, id 00001234, original direction"
id=20085 trace_id=155 func=__ip_session_match_tuple line=2818 msg="Session state: not ready"
id=20085 trace_id=155 func=__ip_session_find_by_session_id line=2773 msg="session session_deny because state proto is not ready"

A FortiGate is blocking HTTP traffic from 10.0.1.5 to 10.0.2.100, despite an explicit allow policy. The exhibit shows the configuration and debug flow output. What is the most likely cause?

⚠ Common exam trap

Candidates often assume a policy issue (wrong interface, wrong action, or wrong address object) when the debug flow shows a session being created but not completing, but the real cause is a DoS protection mechanism that drops the session after the initial SYN.

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

✓

TCP SYN flood protection is dropping the incomplete session.

The debug flow output shows the session is in a 'SYN_RECV' state and never transitions to 'ESTABLISHED', which is characteristic of TCP SYN flood protection. When the FortiGate's SYN flood protection threshold is exceeded, it drops incomplete sessions before they can be fully established, even if an explicit allow policy exists. This explains why HTTP traffic from 10.0.1.5 to 10.0.2.100 is blocked despite the policy being correctly configured.

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 policy is applied to the wrong source interface.
Why it's wrong here
The debug shows the packet received on port1, which matches the policy.
✗
The policy action is set to deny.
Why it's wrong here
Exhibit shows action accept.
✓
TCP SYN flood protection is dropping the incomplete session.
Why this is correct
The 'state proto not ready' indicates TCP handshake incomplete; often due to DoS protection thresholds.
✗
The source address object does not include 10.0.1.5.
Why it's wrong here
The srcaddr is 10.0.1.0/24 which includes 10.0.1.5.

Go deeper

NSE7 Troubleshooting and Diagnostics Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question