NSE7 Advanced VPN and Zero Trust Practice Question
A FortiGate has multiple IPsec VPNs to different branch offices. The administrator notices that one VPN tunnel is flapping (going up and down repeatedly). From the CLI, 'diagnose vpn ike gateway list' shows the gateway state as 'up' but then quickly goes to 'down'. What is the MOST likely cause?
⚠ Common exam trap
NSE7 often tests the misconception that any tunnel problem is a crypto mismatch — candidates pick phase2 or PSK errors, but those prevent establishment, not cause flapping after 'up'.
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
✓
Dead Peer Detection (DPD) retry interval is too short
A flapping IPsec tunnel where the IKE gateway shows 'up' then quickly 'down' is most commonly caused by Dead Peer Detection (DPD) being too aggressive — if the DPD retry interval or retry count is too short, transient packet loss or latency causes the FortiGate to declare the peer dead and tear down the tunnel, which then renegotiates and flaps.
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 remote gateway's certificate is expired
Why it's wrong here
An expired remote certificate fails phase 1 authentication, so the gateway would not reach 'up' in the first place. Certificate expiry is the correct diagnosis when IKE negotiation fails immediately with authentication or validation errors, not when a tunnel establishes and then repeatedly drops.
- ✗
The phase2 proposal is mismatched
Why it's wrong here
A phase 2 proposal mismatch prevents quick mode from completing, so the tunnel never comes up; it does not produce an established-then-flapping pattern. Phase 2 mismatches are the correct diagnosis when phase 1 is up but no selectors or SAs are negotiated.
- ✓
Dead Peer Detection (DPD) retry interval is too short
Why this is correct
An overly aggressive DPD retry interval causes the FortiGate to declare the peer dead before replies arrive, tearing down the IKE SA and forcing renegotiation; the gateway cycles up then down, matching the observed flapping.
- ✗
The pre-shared key is incorrect
Why it's wrong here
An incorrect pre-shared key causes phase 1 authentication to fail outright, so the gateway never reaches 'up' — it cannot explain a tunnel that establishes then drops. A PSK mismatch would be the diagnosis when 'diagnose vpn ike gateway list' shows no established state 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
Courseiva writes every NSE7 question from scratch — 718 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 →
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.