NSE4 Authentication and VPN Practice Question
A company has a FortiGate at headquarters running FortiOS 7.2 and a remote office with a FortiGate 60F running FortiOS 7.0. They have an IPsec VPN tunnel between them for site-to-site connectivity. Recently, the remote office upgraded their FortiGate from 6.4 to 7.0. After the upgrade, the VPN tunnel is down. The Phase 1 status shows 'negotiating' but never completes. The administrator has verified that the pre-shared key, IKE version (IKEv2), and authentication method are the same on both sides. The Phase 1 proposal on the headquarters is: encryption: AES256, SHA256, DH group 14, lifetime 86400. The remote office uses: encryption: AES256, SHA1, DH group 14, lifetime 86400. What is the most likely cause of the failure?
⚠ Common exam trap
Many exam-takers assume all Phase 1 parameters are correct because the pre-shared key, IKE version, and authentication method match, overlooking the critical requirement that the hash algorithm must also be identical for the IKE SA to be established.
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
✓
The Phase 1 hash algorithm differs; headquarters uses SHA256, remote uses SHA1.
The Phase 1 proposal mismatch on the hash algorithm (SHA256 vs. SHA1) prevents the IKEv2 peers from agreeing on a common transform set. Even though all other parameters match, the hash algorithm must be identical on both sides for the IKE SA to be established. The 'negotiating' state that never completes is a classic symptom of a proposal mismatch.
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 DH group is different; headquarters uses group 14, remote uses group 5.
Why it's wrong here
The DH group is not the cause of the failure because both the headquarters and remote FortiGate are already configured with group 14, which uses 2048-bit MODP for key exchange. Since both sides share the same DH group, the Diffie-Hellman proposal matches during IKE negotiation, so this parameter cannot be responsible for the Phase 1 failure. A DH group mismatch would prevent the peers from deriving the same shared secret, but here the groups are identical.
- ✓
The Phase 1 hash algorithm differs; headquarters uses SHA256, remote uses SHA1.
Why this is correct
The Phase 1 hash algorithm (also known as the integrity algorithm) is indeed the mismatch: the headquarters FortiGate expects SHA-256 while the remote peer is configured with SHA-1. During IKE Phase 1 negotiation, both peers exchange proposal payloads containing the hash algorithm, and if the hashes do not match, the IKE SA cannot be established. SHA-1 is outdated and not often the default in FortiOS 7, but if the remote peer still uses it, the SA negotiation fails immediately. This is the correct answer because the hash algorithm must be identical on both VPN endpoints.
- ✗
The IKE version is mismatched; headquarters uses IKEv2 and remote uses IKEv1.
Why it's wrong here
The IKE version is not mismatched because both FortiGate devices are configured to use IKEv2, as the administrator confirmed in the existing note. While IKEv1 and IKEv2 are inherently incompatible and would cause a negotiation failure, that is not what is happening here. Since both peers are on the same IKE version, the IKE version parameter is not the source of the problem.
- ✗
The pre-shared key is incorrect after the upgrade.
Why it's wrong here
The pre-shared key is not the issue because the administrator has already verified that the key is correct after the upgrade. Even if a FortiGate firmware upgrade changes some default settings, it does not modify the configured pre-shared key value. A PSK mismatch would cause an authentication failure after the proposal is negotiated, but since the proposals are not even matching, the failure occurs earlier in IKE negotiation, before PSK authentication.
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.