NSE4 Authentication and VPN Practice Question
You run the command 'diagnose vpn ike log filter name vpn1' and then 'diagnose vpn ike log filter type phase1'. The log shows: 'IKEv1 exchange:f4470f07:00000000: responder: main mode: received IKE_SA_INIT (aggressive mode not allowed)'. What is the problem?
⚠ Common exam trap
Many exam-takers confuse the 'aggressive mode not allowed' message with a proposal mismatch or authentication failure, but the log explicitly states the mode is the issue, not the cryptographic parameters or keys.
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 responder is configured for main mode only, but the initiator is sending aggressive mode
The log message 'aggressive mode not allowed' indicates the responder (FortiGate) is configured to accept only main mode IKE phase1 negotiations, but the initiator sent an aggressive mode request. This mismatch causes the responder to reject the IKE_SA_INIT message, as aggressive mode is disabled by default or explicitly set to main mode only in the phase1 configuration.
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 initiator is using IKEv2 while the responder uses IKEv1
Why it's wrong here
IKEv2 does not use aggressive mode at all; it replaces the IKEv1 exchange types (Main and Aggressive) with IKE_SA_INIT and IKE_AUTH. If the initiator were IKEv2 and the responder only IKEv1, the responder would fail to recognize the IKE_SA_INIT packet and either drop it silently or send an INVALID_IKE_SA notification. The log would not contain an 'aggressive mode' rejection, because no aggressive-mode message exists in IKEv2.
- ✓
The responder is configured for main mode only, but the initiator is sending aggressive mode
Why this is correct
In IKEv1, an aggressive-mode initiator sends its SA proposal, key-exchange material, nonce, and identity in a single packet, while a main-mode-only responder expects the two-round-trip Main Mode sequence (SA exchange first, then KE/nonce). When the responder's phase 1 configuration is set to 'main mode only,' it immediately discards the incoming aggressive-mode packet and logs a mode mismatch such as 'aggressive mode is not supported.' This rejection occurs before any proposal comparison or PSK authentication, so the log indicates a configuration mismatch rather than a cryptographic or proposal failure.
- ✗
The pre-shared key is wrong
Why it's wrong here
A wrong pre-shared key would not surface as a mode mismatch because the aggressive/main mode decision happens in the first IKEv1 exchange, long before authentication. With a PSK mismatch, both peers successfully negotiate the SA and perform the DH key exchange, then fail during authentication when the integrity check or AUTH payload cannot be validated—FortiGate logs would show an authentication failure notification like INVALID_HASH_INFORMATION or 'AUTH failed.' Such an error is specific to credential validation, not to the exchange type, so it cannot explain the mode rejection in the log.
- ✗
The phase1 proposal is incompatible
Why it's wrong here
An incompatible phase 1 proposal would be reported as a NO_PROPOSAL_CHOSEN notification, not as a mode mismatch. The responder in Main Mode or Aggressive Mode first checks the exchange type to decide whether to accept the packet; only after accepting the mode does it evaluate the SA payload's transforms (encryption, authentication, DH group, lifetime). Since the log shows the responder rejecting the exchange mode itself, the proposal has not even been examined yet, so a proposal mismatch is a distinct and later failure point.
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 282-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.