Troubleshooting the "no proposal chosen" error

Product

IPSec VPN

Version

R81 (EOS), R81.10 (EOS), R81.20

Last Modified

2025-10-29

Solution

Table of Contents

• Scenario 1: Site-to-Site VPN fails at Quick Mode Packet 1 with "NO PROPOSAL CHOSEN" error when using IPSEC AH
• Scenario 2: SmartView Tracker shows "No proposal chosen" error even though VPN connects successfully
• Scenario 3: VPN Tunnel encryption negotiation with third-party gateway fails with when using AES-GCM

Scenario 1: Site-to-Site VPN fails at Quick Mode Packet 1 with "NO PROPOSAL CHOSEN" error when using IPSEC AH

Symptoms:

• The $FWDIR/log/ike.elg file contains:
  " Quick Mode fails in packet 1 with notification from Check Point gateway: NO-PROPOSAL-CHOSEN"
• The $FWDIR/log/vpnd.elg file contains:
  [vpnd PID...]@Host[DATE TIME] processPropPayload: received proposal with DEPRECATED AH protocol.
[vpnd PID...]@Host[DATE TIME] payload_list_destroy: return a list of 1 payload
[vpnd PID...]@Host[DATE TIME] processPropPayloadList: ignoring proposal 1
[vpnd PID...]@Host[DATE TIME] payload_list_destroy: return a list of 1 payload
[vpnd PID...]@Host[DATE TIME] processPropPayloadList: ignoring proposal 1, since last prop was ignored.
[vpnd PID...]@Host[DATE TIME] processSAPayload: No valid proposal found.

Cause:

Peer is proposing an unencrypted AH only tunnel in Quick Mode packet 1 as opposed to an ESP tunnel.

Solution:
Check Point does not support an unencrypted AH-only tunnel. Use an encrypted tunnel that is supported.

Scenario 2: SmartView Tracker shows "No proposal chosen" error even though VPN connects successfully

Symptoms:

• SmartView Tracker log shows the log "No proposal chosen" error, even though the VPN connection is actually successful and traffic passes between VPN peers.

Cause:
To overcome old routers' packet handling limitations, the default proposal packet size configuration on VPN-1 Power/UTM is set to small packets. This setting also causes the client application to use an encryption method that does not include advanced packets.

When using an advanced packet encryption algorithm, the connection is eventually successful, but a false error appears because of the default packet size setting.

Solution:
There are two possible solutions for this issue. Do one of these:

Solution 1: Set an older encryption method, such as AES-128 instead of AES-256
01. Open SmartConsole for the Management Server that manages the Remote Access VPN Gateway.
02. Click the upper left menu button > Global Properties.
03. From the left menu, expand Remote Access.
04. Click VPN - Authentication.
05. In the Encryption algorithms section, click Edit.
06. In the IKE Security Association (Phase 1) tab, select the desired algorithms and clear undesired algorithms.
07. In the IKE Security Association (Phase 2) tab, select the desired algorithms and clear undesired algorithms.
08. Click OK.
09. In the Global Properties window, click OK.
10. Install the Security Policy.
11. Reconnect the Remote Access VPN clients.

Solution 2: Change the parameter that controls the size of the proposal group to be used by the VPN client to "large"
01. Open SmartConsole for the Management Server that manages the Remote Access VPN Gateway.
02. Click the upper left menu button > Global Properties.
03. From the left menu, click Advanced.
04. In the Advanced Configuration section, click Configure.
05. From the left menu, expand SecuRemote/SecureClient.
06. Click IKE/IPSec Settings.
07. Set the value of the desktop_ike_p2_prop_size to large.
08. Click OK.
09. In the Global Properties window, click OK.
10. Install the Security Policy.
11. Reconnect the Remote Access VPN clients.

Scenario 3: VPN Tunnel encryption negotiation with third-party gateway fails with when using AES-GCM

Symptoms:

• Site-to-Site VPN based on IKEv2 fails.
• AES-GCM-128 or AES-GCM-256 is configured in the VPN Community encryption settings (SmartConsole > Objects tab > VPN Communities > the relevant VPN Community object > Encryption tab)
• IKE debugs show that the Check Point VPN Gateway proposed another integrity algorithm (example:SHA2) in addition to AES-GCM. See the Site to Site VPN Administration Guide for your version > Command Line Reference section > ike debug page.

Cause:
AES-GCM encryption algorithms do not work with additional integrity algorithms. By design, they include a built-in integrity check.
Solution:
This problem was fixed. The fix is included in:

• Jumbo Hotfix Accumulator for R81.20 starting from Take 53
• Jumbo Hotfix Accumulator for R81.10 starting from Take 139
• Jumbo Hotfix Accumulator for R81 starting from Take 99
• Jumbo Hotfix Accumulator for R80.40 starting from Take 211

If you choose not to upgrade, Check Point can supply a Hotfix. Contact Check Point Support to get a Hotfix for this issue. A Support Engineer will make sure the Hotfix is compatible with your environment before providing the Hotfix. For faster resolution and verification, please collect CPinfo files from the Security Management Server and Security Gateways involved in the case. Hotfix installation instructions:
Refer to sk168597 - How to install a Hotfix. Workaround
If you do not want to download a hotfix, configure an encryption setting that is not AES-GCM. For example, on the Check Point VPN Gateway and the third-party gateway, configure AES-256 + SHA2.

Article Properties

Access Level: General
Status: Approved
Date Created: 2016-12-05
Last Modified: 2025-10-29