IPsec VPN 'no acceptable proposal' in Phase 1: Common Mismatches
A FortiGate administrator is troubleshooting an IPsec VPN that fails to establish. The Phase 1 status shows 'init' and then resets. The administrator runs 'diagnose debug application ike -1' and sees the message 'no acceptable proposal'. Which TWO parameters are MOST likely mismatched?
Quick Answer
The answer is a mismatch in the Diffie-Hellman group and the encryption algorithm. When an IPsec VPN fails to establish and the Phase 1 status shows 'init' before resetting, the 'no acceptable proposal' message in the IKE debug output means the two peers cannot agree on a common set of security parameters during the negotiation process. On the Fortinet NSE 4 Network Security Professional NSE4 exam, this scenario tests your understanding of IKE Phase 1 proposal matching, where both sides must share identical settings for encryption, authentication, and DH group; a common trap is assuming only the pre-shared key is wrong, but the debug clearly points to proposal mismatches. To remember this, think of Phase 1 as a handshake where both parties must speak the same language—if the DH group or cipher doesn’t match, the conversation ends before it starts.
⚠ Common exam trap
Many candidates confuse Phase 1 proposal mismatches (encryption, DH group) with authentication failures (pre-shared key) or Phase 2 mismatches (networks), but the 'no acceptable proposal' error specifically points to cryptographic parameter negotiation failure in Phase 1.
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
✓
Encryption algorithm (e.g., AES256 vs AES128)
The IKE debug message 'no acceptable proposal' means the two peers could not agree on the Phase 1 (IKE SA) proposal parameters, which are negotiated during IKE SA establishment. Option D (encryption algorithm, e.g., AES256 vs AES128) is correct because the encryption algorithm is a Phase 1 proposal attribute, and if the local and remote FortiGates offer different encryption algorithms, no matching proposal exists and negotiation fails. Option E (Diffie-Hellman group, e.g., group 14 vs group 2) is also correct because the DH group is another Phase 1 proposal attribute; mismatched DH groups (modp2048/group 14 vs modp1024/group 2) prevent the peers from agreeing on a proposal. Option A (pre-shared key) is not the cause here because a PSK mismatch produces authentication failure messages (e.g., 'probable pre-shared key mismatch'), not 'no acceptable proposal'. Option B (Phase 2 local and remote networks) is a Phase 2 quick-mode/selector issue and would not generate a Phase 1 proposal rejection. Option C (IKE version) can cause negotiation problems, but a version mismatch typically shows different errors such as 'received IKEv2 packet on IKEv1 tunnel' or invalid version messages rather than the specific 'no acceptable proposal' text.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Pre-shared key
Why it's wrong here
A pre-shared key mismatch fails authentication after the proposal is accepted, producing an authentication error rather than 'no acceptable proposal'. It tempts because PSK errors are a common VPN fault, but they surface at a later Phase 1 stage than proposal negotiation.
- ✗
Phase 2 local and remote networks
Why it's wrong here
Phase 2 networks are negotiated after Phase 1 completes; the 'no acceptable proposal' message during Phase 1 indicates Phase 1 proposal mismatches such as encryption, authentication or DH group. It tempts because network mismatches cause Phase 2 failures, which occur later in the exchange.
- ✗
IKE version (IKEv1 vs IKEv2)
Why it's wrong here
An IKE version mismatch typically produces 'no proposal chosen' or immediate exchange failure, but 'no acceptable proposal' points to Phase 1 encryption, hash, authentication, or DH group differences within the same version. IKE version is tempting because it is a common Phase 1 mismatch, and would be correct if the debug showed version negotiation errors.
- ✓
Encryption algorithm (e.g., AES256 vs AES128)
Why this is correct
'No acceptable proposal' means Phase 1 negotiation found no matching transform set. Mismatched encryption algorithms, such as AES256 on one peer and AES128 on the other, prevent any proposal from being accepted, so the tunnel resets.
- ✓
Diffie-Hellman group (e.g., group 14 vs group 2)
Why this is correct
The 'no acceptable proposal' message means Phase 1 negotiation failed on a parameter both peers must match exactly. The Diffie-Hellman group is one such parameter, and a mismatch between group 14 and group 2 causes the proposal to be rejected, resetting the tunnel to 'init'.
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
Courseiva writes every NSE4 question from scratch — 773 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on NSE4
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. An administrator is troubleshooting an IPsec VPN that fails to establish Phase 2. The Phase 1 is up. The administrator runs 'diagnose vpn ike log' and sees the message 'no matching phase2 proposal found'. What is the MOST likely cause?
hard- A.Pre-shared key mismatch
- B.IKE version mismatch (IKEv1 vs IKEv2)
- C.Phase 1 encryption algorithm mismatch
- ✓ D.Phase 2 proxy ID mismatch
Why D: The message 'no matching phase2 proposal found' indicates that the IPsec security associations (SAs) proposed by the remote peer do not match the local Phase 2 configuration. Phase 2 uses proxy IDs (local/remote subnets and ports) to define which traffic should be encrypted. A mismatch in these proxy IDs, such as incorrect subnet definitions or protocol/port values, prevents the IKE negotiation from completing Phase 2, even though Phase 1 (which authenticates and establishes the IKE SA) is already up.
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.