Why IPsec VPN Phase 2 Fails with Proposal Mismatch
A network administrator is troubleshooting an IPsec VPN tunnel between two FortiGates. Phase 1 is up, but Phase 2 fails to establish. The debug command 'diagnose vpn ike log' shows: 'no suitable proposal found'. What is the most likely cause?
⚠ Common exam trap
A common mix-up: candidates confuse Phase 1 and Phase 2 proposal errors, assuming any 'no suitable proposal found' message relates to Phase 1, but the context of Phase 1 being up explicitly isolates the issue to Phase 2 parameter mismatch.
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
✓
Phase 2 encryption or authentication algorithms do not match on both sides.
The 'no suitable proposal found' error in Phase 2 of an IPsec VPN tunnel indicates that the Phase 2 parameters (encryption algorithm, authentication algorithm, or PFS settings) do not match between the two FortiGate peers. Since Phase 1 is up, the IKE SA is established, meaning pre-shared keys, remote gateway reachability, and basic firewall policies for IKE traffic are correct. The mismatch specifically occurs in the Phase 2 proposal negotiation, where each side sends its supported transforms and the responder cannot find a common set.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Phase 2 encryption or authentication algorithms do not match on both sides.
Why this is correct
Phase 2 (Quick Mode) negotiates the IPsec SA parameters, including the encryption algorithm (e.g., AES-256, 3DES) and authentication algorithm (e.g., SHA-1, SHA-256) for the ESP/AH protocol. If the local and remote firewalls do not offer a common proposal for these algorithms and the Diffie-Hellman group, the Phase 2 negotiation will fail with an error such as 'no proposal chosen.' Since Phase 1 has already formed a secure IKE SA, the problem isolates specifically to a Phase 2 proposal mismatch, preventing the tunnel from establishing even though both gateways are reachable and authenticated.
- ✗
The firewall policy allowing IPsec traffic is missing.
Why it's wrong here
A firewall policy that permits IPsec traffic governs which data flows are allowed to traverse an established VPN tunnel, but it does not drive the IKE Phase 2 negotiation itself. In route-based VPNs the tunnel can establish with no policy present, and in policy-based VPNs the policy's local/remote selectors must match the Phase 2 proxy IDs, but a missing policy would show symptoms like dropped traffic or no matching policy, not a failure to create the Phase 2 IPsec SA. Therefore, if Phase 2 is not coming up, the root cause is not the absence of a firewall policy.
- ✗
The remote gateway IP address is unreachable.
Why it's wrong here
If the remote gateway IP address were unreachable, the FortiGate would be unable to send IKE packets, and Phase 1 would never complete. Because Phase 2 negotiation is only initiated after a successful Phase 1, a reachability failure would abort the process before Phase 2 is ever attempted. Since the administrator observes a Phase 2 failure, the Phase 1 SA exists, which proves the remote gateway is reachable over the network, eliminating this option as the cause.
- ✗
The pre-shared key is incorrect.
Why it's wrong here
An incorrect pre-shared key is used in IKE Phase 1 to authenticate the peers—not in Phase 2. If the PSK does not match, authentication during Phase 1 Main Mode or Aggressive Mode exchange fails, and no IKE SA is established. Thus the Phase 2 Quick Mode would never be invoked, so a PSK mismatch cannot be the explanation for a Phase 2-specific failure; this issue would prevent Phase 1 entirely.
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
2 more ways 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. A network administrator configures an IPsec VPN between two FortiGate devices. Phase 1 completes successfully, but Phase 2 fails to establish. The administrator runs 'diagnose vpn ike log' and sees the error 'proposal mismatch'. What is the MOST likely cause?
medium- A.The IKE version is mismatched (IKEv1 vs IKEv2)
- B.The pre-shared key is incorrect
- C.The firewall policies are blocking IKE traffic on UDP port 500
- ✓ D.The Phase 2 local and remote subnets do not match on both ends
Why D: The error 'proposal mismatch' in the Phase 2 IKE log indicates that the IPsec security associations (SAs) proposed by one FortiGate do not match the configured Phase 2 parameters on the other. Since Phase 1 completed successfully, the IKE version and pre-shared key are already validated. The mismatch specifically refers to the local and remote subnet definitions, encryption algorithms, or authentication methods in the Phase 2 selectors. Therefore, the most likely cause is that the Phase 2 local and remote subnets are not correctly mirrored on both ends.
Variation 2. A network administrator configured an IPsec VPN between two FortiGates. Phase 1 is up, but Phase 2 fails to establish. The diagnose output shows 'no matching proposal'. What is the MOST likely cause?
medium- A.The firewall policy allowing the VPN traffic is missing
- ✓ B.The Phase 2 encryption and authentication algorithms do not match between peers
- C.The pre-shared keys do not match
- D.The remote gateway IP address is incorrect
Why B: The 'no matching proposal' error in Phase 2 indicates that the IPsec security association (SA) parameters—specifically the encryption algorithm, authentication algorithm, or Diffie-Hellman group—do not match between the two FortiGate peers. Phase 2 uses these proposals to negotiate the IPsec SA for protecting data traffic, and a mismatch prevents the tunnel from establishing. Since Phase 1 completed successfully, the pre-shared keys and gateway IP are already verified, isolating the issue to Phase 2 configuration.
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.