NSE4 Authentication and VPN Practice Question
An administrator is troubleshooting an IPsec VPN that fails to establish. The 'diagnose vpn ike log' shows 'initial contact received'. What does this message indicate?
⚠ Common exam trap
The trap here is that candidates often misinterpret 'initial contact' as a configuration mismatch or authentication error, but it is actually a standard IKE notification indicating a peer restart, not a failure cause.
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 remote peer has restarted and cleared its security associations
In IPsec IKE (Internet Key Exchange), an 'initial contact' notification is sent by a peer to inform the other side that it has just restarted or cleared its security associations (SAs). This message tells the receiving peer to delete any existing SAs associated with that peer, allowing a fresh IKE negotiation to begin. Therefore, the message indicates the remote peer has restarted and cleared its SAs, not a configuration or NAT issue.
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 pre-shared key is incorrect
Why it's wrong here
An incorrect pre-shared key will not cause a proposal negotiation failure but will result in an authentication failure during IKE phase 1 (IKEv1 main/aggressive mode) or during the IKE_AUTH exchange in IKEv2. The responder will reject the peer's authentication payload, typically logging a 'received an unauthenticated notification' or 'PSK mismatch' error, and the tunnel will not be established beyond that point.
- ✗
The Phase 1 proposal is mismatched
Why it's wrong here
A mismatch in Phase 1 proposals (encryption algorithm, integrity algorithm, DH group, or PRF) means the two peers cannot agree on a common security parameter set. In IKEv1, this triggers a 'NO_PROPOSAL_CHOSEN' notify response, and in IKEv2 a similar 'NO_PROPOSAL_CHOSEN' occurs, causing the IKE SA to be terminated before any authentication or key exchange can proceed. This failure is immediate and identifiable from the IKE notify message.
- ✓
The remote peer has restarted and cleared its security associations
Why this is correct
When the remote peer restarts (e.g., a firewall reboot or IPsec process restart), it may send an 'Initial Contact' informational message in IKEv2 (or a delete SA notification in IKEv1) to tell the local peer to purge all existing Security Associations for that peer. If the local peer does not process or receive this message, or if the remote peer does not send it, the local peer may still reference a stale SA, causing the tunnel to fail during rekeying or when a new SA is attempted. The 'Initial Contact' mechanism is designed to force the old SAs to be deleted and a new tunnel to be established.
- ✗
A network address translation device is altering the IKE packets
Why it's wrong here
A NAT device altering IKE packets will typically be detected through NAT-D (NAT Discovery) payloads exchanged during IKE phase 1. If NAT is not handled correctly (e.g., not using UDP encapsulation for IPsec), the IKE packets may be dropped or corrupted, but if NAT-T is operating normally, the payloads are encapsulated in UDP and are not 'altered' in a way that breaks authentication. The actual problem with NAT is usually a misconfigured NAT-T policy or a device that fails to pass UDP 500/4500, rather than a generic 'alteration' that would produce a distinguishable IKE error; the administrator would see NAT-D payloads indicating a NAT is present and the tunnel would fail to negotiate if those payloads are missing or mismatched.
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
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.