Understanding the Root Cause: Why Proposals Are Rejected

When an IKEv2 negotiation fails with a “NO_PROPOSAL_CHOSEN” error, the responder is telling the initiator that none of the Security Association (SA) proposals it received are acceptable. This is a proposal mismatch problem: the two peers cannot agree on a compatible combination of algorithms, lifetimes, or other SA attributes during the IKE_SA_INIT or IKE_AUTH exchanges. For administrators, the error looks simple, but the underlying causes can be varied and subtle — from mismatched cipher suites and lifetimes to NAT or fragmentation issues that alter packet contents.

Common Technical Causes

  • Algorithm/Cipher mismatch: Different encryption (AES-GCM, AES-CBC), integrity (SHA1, SHA256), and DH groups (MODP groups, ECP) offered by the initiator do not overlap with the responder’s allowed set.
  • Transform order and preferences: Some stacks treat the first acceptable transform or the first acceptable proposal differently, so ordering matters.
  • Lifetimes and PFS mismatches: Different SA lifetimes or requiring Perfect Forward Secrecy (PFS) with an unsupported DH group can cause no proposal to be chosen.
  • Credential/Proposal coupling: Virtual templates or per-peer policies might bind proposals to certain credentials (PSK vs certs). If credentials do not match the expected policy, proposals are rejected.
  • NAT or fragmentation interference: If the UDP packets carrying IKEv2 messages are fragmented or NAT devices rewrite payloads (or strip options), the responder may see corrupted or incomplete proposals.
  • Vendor-specific limits or defaults: Defaults on firewalls, routers, or cloud VPN gateways may restrict allowed algorithms or have fixed transform sets that differ from open-source defaults.

Gather Essential Diagnostic Data

Before making changes, collect concrete evidence. The following items will make troubleshooting efficient and auditable:

  • IKEv2 logs from both peers (charon/strongSwan, libreswan, Windows Event logs, Cisco/Juniper debugs).
  • Packet captures showing IKE packets (UDP 500 and UDP 4500 if NAT-T is used).
  • IPSec/XFRM state and SA tables on both endpoints (ip xfrm, ipsec statusall, show crypto ikev2 sa).
  • Configuration snippets for the connection/policy on both sides (phase1/phase2 proposals, lifetimes, credential types).

Quick Practical Fixes — Step-by-Step

Below are prioritized, practical steps you can take to resolve most “no proposal” failures. Apply them in order, testing after each change.

1. Confirm and align IKE and ESP proposals

Verify which proposals the initiating peer sends and which proposals the responder accepts. Use packet capture:

Capture command (Linux): tcpdump -n -i eth0 udp port 500 or udp port 4500

Inspect the SA payloads in the IKE_SA_INIT and IKE_AUTH. On strongSwan/libreswan, increase logging (charon.log or pluto logs) and look for the offered transforms and the chosen transform. If you find no overlap, edit one side to include the other’s ciphers.

  • Common modern set: IKE: SHA256, AES-GCM-128/256, DH group 14/19/20/21. ESP: AES-GCM (combined) or AES-CBC with HMAC-SHA256 + PFS group 14.
  • Legacy compatibility: If the peer uses AES-CBC or SHA1, temporarily add that to the responder’s allowed list while migrating both endpoints to stronger suites.

2. Check PSK vs Certificate policy mapping

Many implementations bind specific proposals to credential types. For example, a policy might require a certificate for ECDH groups or certain transforms. If one peer uses a PSK but the responder expects a cert for that transform set, proposals will be rejected.

  • On strongSwan, check ipsec.conf or swanctl.conf connection blocks and the leftauth/rightauth or local/remote authentication settings.
  • If you are using PSK for a given remote, ensure the responder’s policy allows PSK-enabled proposals.

3. Align lifetimes and PFS requirements

Some devices reject a proposal if SA lifetimes are outside accepted ranges or if PFS is required but the offered DH group is unsupported.

  • Verify IKE and ESP lifetimes on both sides. Typical values: IKE SA 3600–28800 seconds, ESP SA 3600–86400 seconds.
  • If one peer insists on PFS, ensure both support the DH group (e.g., group14 or group19).

4. Watch for NAT/fragmentation issues

NAT-T encapsulates ESP in UDP/4500 and modifies headers. Fragmented IKE messages (due to large certificate payloads) may be dropped or reassembled incorrectly by middleboxes.

  • Use tcpdump to see if fragments exist: look for IP fragments or IKE messages split into multiple UDP packets.
  • Enable IKEv2 fragmentation (RFC 8221) on your implementation if available (strongSwan does this by default in modern builds).
  • If you suspect NAT interference, temporarily place both endpoints on the same network to verify whether NAT is the cause.

5. Vendor CLI and config examples

Below are quick references for common platforms. Use these to align proposals.

  • strongSwan: swanctl.conf or ipsec.conf — set ike= and esp= with comma-separated transforms. Example: ike=aes256gcm16-prfsha384-ecp521, esp=aes256gcm16
  • Libreswan/Openswan: in ipsec.conf use ike= and esp= lines. Example: ike=aes256-sha2_256;esp=aes256-sha2_256
  • Cisco IOS/ASR: crypto ikev2 policy 10; encryption aes-cbc-256; integrity sha256; group 14. crypto ipsec transform-set TS esp-aes 256 esp-sha256-hmac
  • Juniper: proposals and policy set in security ike proposal and security ipsec proposal with matching algorithms.

How to Read Relevant Logs

Logs won’t always say “mismatch” explicitly. Look for these clues:

  • strongSwan charon: lines containing “no acceptable proposal”, “NO_PROPOSAL_CHOSEN”, or “no matching proposals”. Use journalctl -u strongswan (or see /var/log/syslog).
  • Libreswan/Openswan: pluto log messages like “NO_PROPOSAL_CHOSEN stage 1”.
  • Cisco: show logging | include IKE or debug crypto ikev2: look for “no matching transform” or “peer not acceptable”.
  • Windows: Event ID 27 or Event ID 8193 sometimes accompany IKE negotiation failures; the Event message may indicate proposal issues.

Advanced Checks and Edge Cases

For stubborn cases, consider these less obvious causes:

  • Transform sub-selector order: Some stacks require the integrity algorithm to be present when using certain AES modes; ordering in the SA payload may affect acceptability.
  • Multiple virtual tunnel interfaces: Profiles or templates may apply different proposal lists per remote identity—verify the identity (IDi/IDr) being used and any associated per-peer profile.
  • Cloud-managed gateways: Cloud VPN services sometimes restrict supported proposals (e.g., AWS, Azure). Check provider documentation for supported IKE/ESP lists and match them exactly.
  • IPv6 vs IPv4 differences: Some implementations treat proposals differently over IPv6; ensure policies exist for the correct IP family.

Practical Example: Debug and Fix Workflow

Follow this concise workflow when you face an instance of the error.

  • Step 1 — Capture: Start tcpdump on both endpoints for UDP ports 500 and 4500 to capture the IKE exchanges.
  • Step 2 — Increase logs: Enable verbose logging for IKE daemon (e.g., charon 2-3 for strongSwan) and capture logs during a reconnect attempt.
  • Step 3 — Analyze: Look at the SA payloads and note the offered IKE/ESP transforms, DH groups, lifetimes.
  • Step 4 — Compare: Cross-check with the responder’s configured allowed transforms (server-side config or appliance GUI).
  • Step 5 — Adjust: Temporarily add an overlapping transform (e.g., add AES256-SHA256 with group14) to the responder. Retry the connection.
  • Step 6 — Harden: After successful connection, remove legacy algorithms and converge both sides on modern, strong suites.

When to Escalate

If you have aligned proposals and still see failures, escalate with these items ready:

  • Complete packet captures and log extracts from both endpoints covering the failed negotiation.
  • Exact configuration snippets for both IKE and IPsec SA proposals (redact sensitive keys if needed).
  • Information about middleboxes/NAT devices between endpoints and whether NAT-T is in use.
  • Software/firmware versions for both peers — differences in IKEv2 implementations sometimes introduce incompatibilities.

Best Practices to Prevent Reoccurrence

  • Standardize a modern, interoperable proposal set across your estate: IKE: AES-GCM where possible, PRF/SHA2 family, and DH group 14/19. ESP: AES-GCM or AES256-GCM, or AES-CBC+HMAC-SHA2 with PFS group14 if necessary.
  • Document per-peer policies including credential types, expected identities, and allowed transforms — store them in a version-controlled repository.
  • Test changes in staging with representative vendor appliances to detect vendor-specific quirks before production changes.
  • Monitor logs and set alerts for negotiation failures so policy drifts are detected early.

In most cases, resolving a “no proposal” failure is a matter of careful comparison between what the initiator offers and what the responder accepts, plus attention to NAT, fragmentation, and policy-to-credential mappings. Start with captures and logs, add an overlapping transform to re-establish connectivity, then iteratively harden toward a secure, compatible set.

For more detailed configuration examples and platform-specific guides, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/