NSE7 Advanced VPN and Zero Trust Practice Question
A network administrator is troubleshooting an IPsec VPN tunnel that is not coming up. The configuration uses IKEv2 with pre-shared keys. The administrator runs 'diagnose vpn ike log-filter' and sees no logs. What is the most likely cause?
⚠ Common exam trap
NSE7 often tests the two-step nature of FortiGate debugging, so the trap is assuming that setting the log-filter is sufficient and then misdiagnosing the silence as a PSK or reachability problem.
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
✓
IKE debug is not enabled
The diagnose vpn ike log-filter command sets a filter for which IKE negotiations to log, but it does not itself enable logging — the administrator must also run diagnose debug application ike -1 (or the equivalent debug enable command) to actually turn on IKE debug output. Seeing no logs after setting a filter is the classic symptom of debug not being enabled. The filter only narrows what would be logged if logging were active.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
IKE debug is not enabled
Why this is correct
IKEv2 negotiation events are only captured once the IKE log filter is applied and debug output is active; without enabling IKE debugging, 'diagnose vpn ike log-filter' produces no output, so the tunnel's failure remains invisible.
- ✗
The pre-shared key does not match
Why it's wrong here
A mismatched pre-shared key produces IKEv2 authentication failure logs, so entries would appear once negotiation starts. This is the classic cause of a tunnel failing after Phase 1 begins, but it cannot explain a completely silent log filter.
- ✗
The remote gateway is unreachable
Why it's wrong here
An unreachable gateway would still generate IKE negotiation attempts and log entries, so the absence of logs points elsewhere. Reachability is tested with ping or packet capture, and this option would fit if the filter were working but no packets arrived at all.
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.