NSE7 Troubleshooting and Diagnostics Practice Question
A FortiGate is configured with a VIP (virtual IP) for an internal web server at 10.0.0.10, mapping to public IP 203.0.113.5. External users report that they cannot access the web server, but internal users can access it using the private IP. The administrator runs 'diagnose debug flow filter addr 203.0.113.5' and 'diagnose debug flow show function-name enable' and sees the following output: 'id=20085 trace_id=1 func=print_pkt_detail line=4793 msg="vd-root:0 received a packet(proto=6, 203.0.113.5:443->198.51.100.10:54321) from port1. flag [S], seq 123456, ack 0, win 8192"' followed by 'id=20085 trace_id=1 func=init_ip_session_common line=4970 msg="allocate a new session-00000123"' and then 'id=20085 trace_id=1 func=vf_ip_route_input_common line=2580 msg="find a route: flag=04000000 gw-10.0.0.10 via port2"'. No further output appears. What is the MOST likely cause of the issue?
⚠ Common exam trap
The trap here is assuming that a missing firewall policy is the cause, but the debug flow shows a session was allocated, indicating the policy likely matched.
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 internal web server is not responding to the SYN packet, or the return traffic is being dropped by the FortiGate.
The debug flow output indicates that the FortiGate received the SYN packet, allocated a session, and performed a route lookup to forward the packet to the internal server. However, no further output appears, meaning the FortiGate did not receive a SYN-ACK from the server. This points to either the server not responding or the return traffic being blocked. The administrator should verify the server's availability and check for asymmetric routing or missing return policies that could drop the response.
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 VIP is configured with port forwarding, but the external port does not match the internal port.
Why it's wrong here
Port forwarding misconfiguration would typically result in the FortiGate dropping the packet or forwarding it to the wrong port, but the debug flow shows the packet being routed to 10.0.0.10. If the port were mismatched, the packet might be dropped with a specific error, or the session would show the translated port. The absence of a response suggests the issue is with the server or return path, not port translation.
- ✗
The VIP is not configured with the correct external IP address.
Why it's wrong here
The debug flow output shows that the FortiGate received a packet destined to 203.0.113.5, which is the VIP's external IP, and it allocated a session. If the VIP were misconfigured, the packet would likely be dropped earlier. The presence of the VIP mapping is implied by the session allocation and route lookup. Therefore, the external IP configuration is not the issue.
- ✓
The internal web server is not responding to the SYN packet, or the return traffic is being dropped by the FortiGate.
Why this is correct
The debug flow output ends after the route lookup, meaning the FortiGate forwarded the packet to the internal server but did not receive a response. This indicates that either the server is not responding (e.g., service down, firewall on server) or the return traffic is being dropped by the FortiGate. Common causes include asymmetric routing, missing return policy, or the server's default gateway not pointing to the FortiGate. The administrator should check the server's status and the FortiGate's session table for return traffic.
- ✗
The firewall policy that allows traffic from the external interface to the VIP does not exist or is incorrect.
Why it's wrong here
If the firewall policy were missing, the debug flow would typically show a policy lookup failure and a drop message. Instead, the output shows a session being allocated and a route lookup, indicating that a policy likely matched and the packet is being processed. The absence of further output suggests the packet is being dropped later, not at policy lookup.
Visual reference
Quick reference
Asymmetric Encryption Algorithm Comparison
| Algorithm | Key Exchange | Signatures | Equivalent Security Key | Notes |
|---|---|---|---|---|
| RSA-3072 | Yes | Yes | 128-bit | Widely deployed; slow for bulk data |
| ECDSA P-256 | No | Yes | 128-bit | Fast signatures; standard TLS certs |
| ECDH / ECDHE | Yes | No | 128-bit | Perfect forward secrecy in TLS 1.3 |
| DH / DHE | Yes | No | 128-bit (3072-bit key) | Replaced by ECDHE in modern TLS |
| Ed25519 | No | Yes | ~128-bit | SSH keys, modern PKI |
Go deeper
Related to this question
About these practice questions
This NSE7 question is part of Courseiva's 718-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
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 NSE7 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 NSE7 exam.