When an IKEv2 VPN tunnel fails with the cryptic message “No Proposal Chosen”, administrators often face a frustrating hunt through cryptographic suites, lifetimes, and vendor-specific quirks. This article walks through the typical causes, how IKEv2 negotiates proposals, diagnostic techniques, and practical fixes tailored for common implementations such as strongSwan, LibreSwan, Cisco/IOS/XR, and Windows. The guidance is aimed at webmasters, enterprise IT, and developers managing dedicated IP VPN endpoints.

Why the error happens: a quick conceptual recap

IKEv2 establishes a secure channel by negotiating a set of parameters in two phases: IKE_SA (phase 1) and CHILD_SA (phase 2). Each side sends one or more proposals containing transforms for algorithms like encryption (AES-GCM, AES-CBC), integrity (SHA1, SHA256), Diffie-Hellman groups (MODP2048, ECP), and lifetimes. The message “No Proposal Chosen” means the responder could not find any proposal in the initiator’s offer that matched its own acceptable transforms. That could be due to algorithm mismatches, policy/lifetime conflicts, or packet path issues that alter the packets.

Common root causes

Below are the most frequent reasons this negotiation fails.

1. Crypto algorithm and transform mismatches

  • One side offers AES-GCM (integrity+encryption combined) while the other accepts only AES-CBC with separate integrity like SHA1 — they are incompatible.
  • Mismatched DH groups (e.g., initiator offers group 14 while responder requires group 19/ECP) will fail selection.
  • Different PRFs (pseudo-random functions) or ESP sequence options (e.g., ESP with ESN required on one side).

2. Lifetime and proposal ordering policies

Some implementations treat lifetime or proposal order strictly. If the responder’s policy expects a particular ordering or lifetime value, and the initiator’s proposals don’t match, negotiation can be refused with no chosen proposal.

3. NAT/fragmentation and UDP encapsulation issues

  • Packet modification by NAT devices (such as altering ports) can break IKEv2 negotiation. While NAT-T (UDP encapsulation) usually handles this, some middleboxes corrupt extension attributes.
  • Large proposal payloads that exceed MTU without proper fragmentation can lose attributes; the responder then sees incomplete proposals.

4. Vendor-specific policy and strict matching

Some platforms (notably older Cisco IOS, certain Windows builds, or custom vendor stacks) do exact-match checks and don’t perform flexible negotiation. That can reject otherwise compatible suites if ordering or specific flag bits differ.

5. Misconfigured identity / policy mismatches

If the responder maps policies to peers based on identity or ID types (address, FQDN, or user FQDN), and the initiator sends an unexpected ID type, the responder may apply a policy that has no matching proposals.

How to systematically troubleshoot

Follow this structured approach to identify the precise mismatch and apply the right fix.

Step 1 — Capture logs and packet traces

  • Enable verbose IKE logs on both endpoints. For strongSwan use ‘charon’ debug level (e.g., ipsec start –debug or set log level in strongswan.conf). For Linux kernel IKEv2, check syslog and /var/log/auth.log.
  • Perform a packet capture (tcpdump or Wireshark) on the path. Filter on UDP ports 500 and 4500. Inspect the IKE_SA_INIT and IKE_AUTH exchanges and look at the SA payloads and Notify messages that contain the “NO_PROPOSAL_CHOSEN” payload (Nat 14).
  • On Windows, use the built-in Event Viewer and the Network Monitor (or Message Analyzer) to capture IKE failures; check error codes listed in System/Application logs.

Step 2 — Compare proposals side-by-side

From the capture/logs, extract the list of transforms offered by the initiator and those the responder accepts. Typical items to compare:

  • Encryption algorithm and mode (AES-GCM-16, AES-CBC-256)
  • Integrity algorithm (SHA1, SHA256, AES-GMAC)
  • DH group numbers (group14, group19, group20, etc.)
  • PRF and extended sequence number (ESN) settings
  • Lifetimes (from seconds to kilobytes)

Step 3 — Check identity and policy mapping

Ensure the responder is applying the policy you expect. On RADIUS or policy-based gateways, make sure the peer identity (IDr) matches the configured peer entry. If the responder has no policy for that identity, it may offer an empty set of proposals.

Step 4 — Evaluate MTU and NAT behavior

Large proposals or many transforms can create packets exceeding the path MTU and drop on the way. Try reducing the number of proposals or the size of certificate payloads (use compressed certs or avoid sending full chains during initial tests). Test with UDP encapsulation (NAT-T) forced on to see if behavior changes.

Implementation-specific fixes

The proper fix depends on which implementation you run. Below are practical adjustments for common stacks.

strongSwan and libreswan

  • Adjust ipsec.conf/strongswan.conf proposal sets. Example: in strongSwan use ‘ike=aes256-sha256-modp2048’ and ‘esp=aes256gcm16-modp2048’ and ensure both sides have overlapping configuration.
  • Enable IKEv2 opportunistic rekey settings if lifetimes differ: set rekey=yes and control ‘rekeymargin’ and ‘keylife’ so proposals overlap.
  • Use ‘conn %default’ defaults to produce consistent proposals and reduce accidental mismatches.
  • Check charon logs (daemon) for details: set log to ‘charon { filelog { /var/log/charon.log; time_format = %b %e %T; } }’ and increase level to 2-3 for proposal negotiation traces.

Cisco IOS / ASA / IOS-XE / IOS-XR

  • Match the transform sets exactly. Example for IOS: crypto ikev2 policy 10; encryption aes-gcm; group 19; integrity null; prf sha256. Then configure the ikev2 proposal to match.
  • Watch for vendor defaults — some Cisco platforms prefer exact lifetimes and won’t negotiate down; set the lifetime to match the peer’s configuration.
  • For ASA, ensure the crypto map or tunnel-group has correct proposal sets and check ‘show crypto ikev2 sa’ for negotiation breakdowns.

Windows Server / Windows Clients

  • Windows often expects specific combinations (for example, prefer AES-CBC+SHA1 on older versions). Use PowerShell or registry to allow modern suites: enable AES-GCM or SHA256 in the security policy if required.
  • For Always On VPN or RRAS, confirm the server is configured for EAP or PSK as the client expects. A mismatch in authentication method can surface as no proposal chosen in some log contexts.

Advanced diagnostic tips

Inspect the Notify payloads

The responder usually sends a Notify message with NO_PROPOSAL_CHOSEN and sometimes includes an explanation or a list of acceptable transforms. Examine the IKE payloads in Wireshark to see if there’s additional information (e.g., preferred encryption suite).

Reduce variables by testing a minimal configuration

Temporarily simplify both sides to a minimal, known-good set such as:

  • IKE: AES128-SHA256-modp2048
  • ESP: AES128-SHA256-modp2048
  • Lifetime: 3600s

If the minimal set succeeds, gradually expand to the production set to find the breaking element.

Check for firmware or known bugs

Search vendor release notes. Some platforms had bugs where proposals with AES-GCM were rejected unless in a specific order or when combined with EAP. Apply recommended patches or change ordering to work around such issues.

Practical checklist to resolve the issue

  • Enable verbose logs and capture IKE packets on both sides.
  • Compare and align transform sets: encryption, integrity, PRF, DH group, and lifetimes.
  • Ensure policy mapping uses the expected identity type.
  • Force NAT-T if NAT or middleboxes are present; verify fragmentation and MTU.
  • Test with a minimal compatible proposal to confirm basic connectivity.
  • Refer to vendor docs for exact syntax and known interoperability notes.

Dealing with “No Proposal Chosen” is mainly a process of reduction — find the smallest set of transforms that work, then expand. With careful logging and a methodical approach to comparing SA payloads, most causes are quickly identified and fixed.

For more hands-on guides, configuration examples, and advanced troubleshooting articles related to dedicated IP VPNs, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/.