NSE4 Authentication and VPN Practice Question
A company with multiple remote sites uses IPsec VPNs. One site reports intermittent connectivity. The administrator checks the logs and sees 'IPsec phase 2 negotiation failed' messages. Which configuration change is most likely to resolve the issue?
⚠ Common exam trap
The trap here is that candidates often mistake intermittent phase 2 failures for a cryptographic or NAT issue, but the real cause is typically a mismatch in SA state between peers, which DPD is specifically designed to detect and recover from.
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
✓
Enable Dead Peer Detection (DPD) on the Phase 1 interface.
Intermittent IPsec phase 2 negotiation failures often occur when one peer's Phase 2 security association (SA) expires while the other peer still considers it valid, causing a mismatch. Enabling Dead Peer Detection (DPD) on the Phase 1 interface allows the FortiGate to actively probe the peer's liveness and renegotiate Phase 1 and Phase 2 SAs before they expire, preventing the state mismatch that leads to intermittent failures.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Enable Dead Peer Detection (DPD) on the Phase 1 interface.
Why this is correct
DPD (Dead Peer Detection) sends periodic IKE keepalives to the remote gateway to confirm liveness. If no response is received, DPD marks the peer dead, tears down the stale IPsec SA, and triggers a fresh Phase 1/Phase 2 negotiation. This recovers quickly from transient routing or peer failures, which is exactly what your intermittent VPN drops suggest. Without DPD, the SA persists until its natural lifetime expires, causing a long blackout and requiring manual restart.
- ✗
Change the encryption algorithm from AES256 to 3DES.
Why it's wrong here
The intermittent drops are almost certainly a liveness-detection issue, not a cipher-strength problem. AES256 and 3DES are both encryption algorithms; if the remote site is configured with AES256 as the only accepted proposal, switching your side to 3DES creates an SA payload mismatch that prevents IKE negotiation altogether. This would turn the temporary drops into a permanent outage, because the Phase 1 and Phase 2 proposals would no longer align. Therefore, this change cannot fix the real issue and would actually make things worse.
- ✗
Increase the Phase 2 lifetime.
Why it's wrong here
Increasing the Phase 2 lifetime defers the rekey interval, postponing the moment when a new IPsec SA must be negotiated. However, the underlying problem is that the remote peer is sometimes unreachable or unresponsive during that negotiation, so after the extended lifetime expires, the same failure will recur. Many VPN implementations also enforce a maximum lifetime, so you could only delay the inevitable rather than eliminate it. This approach merely masks the symptom and does not repair the broken peer-detection mechanism.
- ✗
Enable NAT traversal.
Why it's wrong here
NAT traversal (NAT-T) encapsulates ESP in UDP to pass through network address translation devices, but your scenario does not mention NAT anywhere in the path. If both endpoints have public, routable addresses and no device is translating them, enabling NAT-T has no effect on peer liveness or on how often IKE negotiation fails. In fact, adding NAT-T when it is not needed can introduce extra overhead and even complicate the tunnel. The intermittent nature of the drops points to DPD, not to NAT detection.
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 NSE4 question is part of Courseiva's 773-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 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.