NSE4 Authentication and VPN Practice Question
A FortiGate administrator is troubleshooting an IPsec VPN that is dropping traffic intermittently. The administrator runs 'diagnose vpn ike log' and sees many 'DPD' messages. Which THREE conditions could cause frequent DPD (Dead Peer Detection) retransmissions? (Choose three.)
⚠ Common exam trap
Many candidates confuse DPD retransmissions with Phase 2 misconfigurations, but DPD operates at Phase 1 and is unrelated to proxy IDs or IKE version mismatches, which prevent tunnel establishment entirely.
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
✓
High network latency causing DPD timeouts
High network latency can cause DPD packets to exceed the configured timeout interval, triggering retransmissions. DPD relies on timely responses; if the round-trip time (RTT) consistently exceeds the DPD retry interval, the FortiGate will send repeated DPD messages, leading to intermittent traffic drops as the tunnel may be torn down.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
High network latency causing DPD timeouts
Why this is correct
High network latency can exceed the DPD dead-peer detection timeout. When FortiGate sends R-U-THERE messages to the peer, it expects an ACK within a configured interval (often multiple retries with a given timeout). On WAN links with significant latency or jitter, that round-trip time can exceed the threshold, causing FortiGate to declare the peer dead and take down the VPN tunnel even though the remote peer is actually operational. This is a common cause of intermittent tunnel flaps on satellite or transcontinental links.
- ✓
The remote peer is rebooting or unstable
Why this is correct
If the remote peer reboots or becomes unstable, it loses its IKE and IPsec security associations and may be unable to respond to DPD probes. The peer's IKE process is either unresponsive or restarted, so the FortiGate does not receive the expected R-U-THERE-ACK within the timeout window. Consequently, DPD correctly identifies that the peer is no longer alive and tears down the tunnel. This is one of the primary legitimate reasons DPD is used: to detect a remote device that has gone offline without sending a proper Delete notification.
- ✗
Mismatched IKE version
Why it's wrong here
An IKE version mismatch (e.g., one end configured for IKEv1 and the other for IKEv2) prevents Phase 1 negotiation from ever succeeding, so no IKE SA is established and the tunnel never becomes operational. Since DPD operates on an established IKE SA, it cannot run if Phase 1 complete; the failure occurs earlier in the process. Therefore, a version mismatch would not result in DPD timeouts—it would simply block tunnel creation entirely, which is a different failure mode.
- ✗
Incorrect Phase 2 proxy IDs
Why it's wrong here
Phase 2 proxy IDs define the traffic selectors (local and remote subnets) that the IPsec tunnel protects. Misconfigured proxy IDs cause Phase 2 negotiation failures—the IKE SA may still be healthy, but the IPsec SA will not be established. DPD is a Phase 1 (IKE) aliveness check that uses the IKE SA; it is completely independent of the traffic selectors. As a result, incorrect proxy IDs do not affect DPD behavior, so they cannot cause DPD timeouts.
- ✓
A firewall between the peers dropping UDP port 500 packets
Why this is correct
DPD relies on IKE packets, which are encapsulated in UDP port 500 (or UDP 4500 if NAT-T is in use). If an intermediate firewall silently drops UDP port 500 traffic, the FortiGate's R-U-THERE requests never reach the peer, and the peer's responses also get lost. To DPD, this looks exactly like an unresponsive peer, so the FortiGate times out and marks the tunnel down even though the remote device is fully operational. This highlights why perimeter firewall rules must allow both UDP 500 and UDP 4500 for IPsec VPNs to remain stable.
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
One of 773 original NSE4 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This NSE4 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 NSE4 exam.