NSE4 Authentication and VPN Practice Question
A FortiGate administrator wants to configure a dial-up IPsec VPN where remote users connect using VPN clients with pre-shared key authentication. The company has recently experienced a data breach where the PSK was compromised. What is the best method to improve security without changing all clients immediately?
⚠ Common exam trap
Many exam-takers confuse user authentication (XAuth) with Phase 1 authentication, mistakenly believing that adding a second factor like FortiToken fixes the compromised PSK, when in fact the PSK is still used and vulnerable in the initial IKE exchange.
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
✓
Migrate to certificate-based authentication for Phase 1
Migrating to certificate-based authentication eliminates reliance on a static pre-shared key (PSK), which is inherently vulnerable to compromise. Certificates provide asymmetric cryptographic proof of identity, ensuring that even if a PSK is leaked, the attacker cannot authenticate without a valid certificate. This is the most robust long-term fix for PSK compromise in IPsec VPNs.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Switch to aggressive mode with a complex PSK
Why it's wrong here
Aggressive mode (IKEv1) with a complex PSK is still fundamentally a shared-secret Phase 1. In aggressive mode, the peer's identity and a hash derived from the PSK are exchanged in cleartext before the IKE SA is encrypted, allowing an offline dictionary attack to recover the PSK. Even a complex PSK is a single static key shared among all dial-up peers, so it must be manually distributed and rotated, and a single endpoint compromise exposes the entire VPN.
- ✗
Enable XAuth with a second authentication factor using FortiToken
Why it's wrong here
XAuth with FortiToken adds a second authentication factor, but it occurs after Phase 1 and does nothing to protect the Phase 1 PSK. An attacker who obtains the PSK can still complete the IKE SA and then only needs to pass the XAuth check; while FortiToken strengthens user identity, the device-level shared secret remains the same weak link. This solution layers a user-authentication milestone on top of a broken cryptographic foundation rather than replacing the shared secret itself.
- ✗
Increase the PSK length to 64 characters
Why it's wrong here
Increasing the PSK length to 64 characters improves resistance to brute-force attacks, but it does not change the architectural weakness that all dial-up clients must embed the same static PSK. A longer PSK is still a single shared secret, so a compromise of one endpoint or one VPN configuration file silently exposes the key to the entire remote-access group. This approach merely strengthens the existing flawed model; it does not provide per-peer identity or the ability to revoke one client without reconfiguring every other peer.
- ✓
Migrate to certificate-based authentication for Phase 1
Why this is correct
Certificate-based Phase 1 authentication replaces the shared PSK with a unique asymmetric key pair per dial-up peer, binding each client's identity to its certificate. During IKE main mode, certificates enable mutual authentication without ever transmitting a shared secret in the clear, and compromised certificates can be individually revoked via a CRL or OCSP without affecting other peers. This eliminates the single-point-of-failure shared secret and is the correct way to harden a dial-up IPsec VPN.
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 282 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.