NSE7 Troubleshooting and Diagnostics Practice Question
A FortiGate is configured with a site-to-site IPsec VPN to a remote peer. The administrator notices that the VPN tunnel is up, but traffic is not passing through it. The administrator runs 'diagnose vpn tunnel list' and sees that the tunnel is established with the correct selectors. The administrator then runs 'diagnose debug flow filter addr 10.1.1.1' (the remote subnet) and 'diagnose debug flow show function-name enable', and observes the following output: 'id=20085 trace_id=1 func=print_pkt_detail line=4793 msg="vd-root:0 received a packet(proto=6, 10.1.1.1:80->192.168.1.100:12345) 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-192.168.1.1 via port2"'. No further output appears. What is the MOST likely cause of the issue?
⚠ Common exam trap
The trap here is assuming the VPN tunnel configuration is at fault, but the debug flow clearly shows the traffic is being routed out the default gateway instead of the tunnel.
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 FortiGate is routing the traffic to the default gateway instead of into the IPsec tunnel, likely due to a missing or incorrect route for the remote subnet.
The debug flow output shows that the FortiGate received the packet, allocated a session, and then performed a route lookup that resulted in a route via the default gateway (192.168.1.1) on port2. This means the FortiGate is not sending the traffic into the IPsec tunnel, which would be indicated by a route via the IPsec interface. The most likely cause is that there is no static route for the remote subnet pointing to the IPsec tunnel. Without that route, traffic is routed to the default gateway and not encrypted. The administrator should verify the routing table and add the necessary route.
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 FortiGate is routing the traffic to the default gateway instead of into the IPsec tunnel, likely due to a missing or incorrect route for the remote subnet.
Why this is correct
The debug flow output shows that the FortiGate performed a route lookup and found a route to 192.168.1.1 via port2, which is the default gateway, not the IPsec tunnel. This indicates that there is no specific route for the remote subnet 10.1.1.0/24 pointing to the IPsec interface. Without that route, the FortiGate sends the traffic out the default gateway, where it is likely dropped or not encrypted. The administrator should add a static route for the remote subnet with the IPsec interface as the outgoing interface.
- ✗
The IPsec VPN tunnel is not included in the firewall policy that allows traffic from the local subnet to the remote subnet.
Why it's wrong here
If the VPN tunnel were not included in the firewall policy, the debug flow would typically show a policy lookup failure or a drop due to no matching policy. 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 issue is not policy inclusion.
- ✗
The IPsec tunnel is using a different encryption domain than the local subnet, causing the FortiGate to drop the traffic.
Why it's wrong here
If the encryption domain (proxy ID) did not match, the tunnel would not establish or the traffic would be dropped with a 'no matching IPsec selector' error. The debug output does not show such an error; instead, it shows a route lookup to a gateway. The issue is routing, not encryption domain mismatch.
- ✗
The remote subnet is not correctly configured in the phase 2 selectors, causing traffic to be routed incorrectly.
Why it's wrong here
The administrator already verified that the tunnel is up with correct selectors using 'diagnose vpn tunnel list'. If the selectors were incorrect, the tunnel would likely not establish or traffic would be dropped with a specific error. The debug output shows a route lookup to a gateway, not a selector mismatch.
Visual reference
Quick reference
VPN Protocol Comparison
| Protocol | Port | Encryption | Authentication | Use Case |
|---|---|---|---|---|
| IKEv2 / IPsec | UDP 500 / 4500 | AES-256 | Certificates / PSK | Site-to-site & remote access |
| SSL / TLS VPN | TCP 443 | TLS 1.3 | Certificates / MFA | Clientless remote access |
| L2TP / IPsec | UDP 1701 | AES (IPsec) | PSK / Certificates | Legacy remote access |
| WireGuard | UDP 51820 | ChaCha20 | Public keys | Modern high-performance VPN |
| PPTP | TCP 1723 | MPPE (weak) | MS-CHAPv2 | Legacy — avoid in production |
PPTP is considered insecure. IKEv2/IPsec and SSL VPN are the current recommended options.
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.