Support Center > Search Results > SecureKnowledge Details
Troubleshooting the "no proposal chosen" error
Solution

Table of Contents

  • Various Scenarios
    • Scenario 1: Site-to-Site VPN with 3rd party DAIP Gateway fails with "no proposal chosen" error
    • Scenario 2: VPN tunnel on Security Gateway 80 appliance does not come up after rebooting Security Gateway 80
    • Scenario 3: Site-to-Site VPN fails at Quick Mode Packet 1 with "NO PROPOSAL CHOSEN" error when using IPSEC AH
    • Scenario 4: SmartView Tracker shows "No proposal chosen" error even though VPN connects successfully
    • Scenario 5: Site-to-Site VPN using IKEv2 fails when SecureXL is enabled
    • Scenario 6: Mac OS VPN Clients are unable to connect using SHA-2
    • Scenario 7: Site to site with DAIP Gateway fail with "No Proposal Chosen" sent by the central Gateway
Click Here to Show the Entire Article

Various Scenarios

There are quite a number of scenarios, in which you may encounter the "no proposal chosen" error. The scenarios that we have encountered and dealt with are detailed below.

Scenario 1: Site-to-Site VPN with 3rd party DAIP Gateway fails with "no proposal chosen" error

Product: IPSec VPN

Symptoms:

  • VPN tunnel with 3rd party gateway is not established and the following error is seen in the SmartView Tracker:
    "Main Mode local machine configured not to respond to unknown IP addresses" (i.e. not exportable for SR, and/or not included in the RemoteAccess community)

  • Debug of VPND daemon (per sk89940) on Check Point Security Gateway shows:
    MMProcess5Epilogue1: refused negotiation from mobile client

Cause:

Check Point Security Gateway treats the 3rd party gateway's certificate as a User Certificate. This ends with failure since the peer gateway is not a user.
As a result, the Check Point Gateway drops the connection in IKE Main Mode packet 5 for "no proposal chosen".

Example from the VPND debug:

[vpnd ...]...           < FWIKE_MM_PACKET_5_FETCH_PEER >    Id = N 
[vpnd ...]... MMProcess5FetchPeer: stage=0; idType=X;         peer_cannot_be_user=0; peer_cannot_be_dag=0;         peer_is_mobile_ip=1; peer_is_dag=0 
[vpnd ...]...           < FWIKE_MM_PACKET_5_EPILOGUE1 >    Id = N 
[vpnd ...]... MMProcess5Epilogue1: refused negotiation from mobile client 
[vpnd ...]... GetDAGIP: ID Hex_IP_Address not in DAIP range 
.......... 
[vpnd ...]... RespMMPacketError: error in FWIKE_EXCH_MAIN_MODE - FWIKE_MM_PACKET_5_EPILOGUE1 
.......... 
[vpnd ...]... findSAByPeer: Valid ISAKMP SA was not found. me=0, peer=Hex_IP_Address
 .......... 
[vpnd ...]... find_sa_by_ike_peer: Find IKE SA for IKE peer 
[vpnd ...]... find_sa_by_ike_peer: No IKE SA for this IKE peer found 
.......... 
[vpnd ...]... Sent Notification to Peer Hex_IP_Address: no proposal chosen 
[vpnd ...]...         Sent Notification to Peer: no proposal chosen 
[vpnd ...]... GetDAGIP: ID Hex_IP_Address not in DAIP range

Solution:

This problem was fixed. The fix is included in:

Check Point recommends to always upgrade to the most recent version (Security Gateway).

For other supported versions, Check Point Support can supply a Hotfix.

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:

  1. Hotfix has to be installed on Security Gateway.

    Note: In cluster environment, this procedure must be performed on all members of the cluster.
  2. Procedure:

    • On Gaia OS - using CPUSE:

      Refer to sk92449: CPUSE - Gaia Software Updates (including Gaia Software Updates Agent):

      • Section "(4-A-c)" / "(4-A-d)" - refer to import instructions for Offline procedure
      • Section "(4-B-a)" - refer to installation instructions for Hotfixes

      Note: Reboot is required.

    • On SecurePlatform/Linux/IPSO OS - using Legacy CLI:

      1. Transfer the hotfix package to the machine (into some directory, e.g., /some_path_to_fix/).

      2. Unpack and install the hotfix package:

        [Expert@HostName]# cd /some_path_to_fix/
        [Expert@HostName]# tar -zxvf fw1_wrapper_<HOTFIX_NAME>.tgz
        [Expert@HostName]# ./fw1_wrapper_<HOTFIX_NAME>

        Note: The script will stop all of Check Point services (cpstop) - read the output on the screen.
      3. Reboot the machine.

Scenario 2: VPN tunnel on Security Gateway 80 appliance does not come up after rebooting Security Gateway 80

Product: IPSec VPN, Security Gateway 80

Symptoms:

  • VPN tunnel on Security Gateway 80 appliance does not come up after rebooting Security Gateway 80.


  • Debug of VPND daemon (per sk89940) on Security Gateway 80's VPN Peer shows:

    [vpnd ...]...           < FWIKE_MM_PACKET_5_FETCH_PEER >    Id = N
    [vpnd ...]... MMProcess5FetchPeer: stage=0; idType=X;
            peer_cannot_be_user=0; peer_cannot_be_dag=0;
            peer_is_mobile_ip=1; peer_is_dag=0
    [vpnd ...]...           < FWIKE_MM_PACKET_5_EPILOGUE1 >    Id = N
    [vpnd ...]... MMProcess5Epilogue1: refused negotiation from mobile client
    [vpnd ...]... GetDAGIP: ID Hex_IP_Address not in DAIP range
    ..........
    [vpnd ...]... RespMMPacketError: error in FWIKE_EXCH_MAIN_MODE - FWIKE_MM_PACKET_5_EPILOGUE1
    ..........
    [vpnd ...]... findSAByPeer: Valid ISAKMP SA was not found. me=0, peer=Hex_IP_Address
    ..........
    [vpnd ...]... find_sa_by_ike_peer: Find IKE SA for IKE peer <Dec_IP_Address,0000000000000000>
    [vpnd ...]... find_sa_by_ike_peer: No IKE SA for this IKE peer found
    ..........
    [vpnd ...]... Sent Notification to Peer Hex_IP_Address: no proposal chosen
    [vpnd ...]...         Sent Notification to Peer: no proposal chosen
    [vpnd ...]... GetDAGIP: ID Hex_IP_Address not in DAIP range

Cause:

VPN Peer treats the Security Gateway 80's certificate as User Certificate, which ends with failure since Security Gateway 80 is not a user. As a result, the VPN Peer drops the connection in IKE Main Mode packet 5 for "no proposal chosen".

Solution:

This problem was fixed. The fix is included in:

Check Point recommends to always upgrade to the most recent version.

 

For other versions, 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.

 

Note: This hotfix has to be installed on the VPN Gateway (with which Security Gateway 80 establishes a VPN tunnel), so it could recognize the Security Gateway 80 correctly.

 

Temporary workaround is to terminate the VPN tunnel on the VPN Gateway (with which Security Gateway 80 established a VPN tunnel), so the VPN Gateway will initiate the VPN tunnel, and not the Security Gateway 80.

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

Product: IPSec VPN

Symptoms:

  • "From ike.elg: "Quick Mode fails in packet 1 with notification from Check Point gateway: NO-PROPOSAL-CHOSEN"

  • From vpnd.elg:
    [vpnd 8273 2012165824]@bbudrgw1[3 Jun 13:13:39] processPropPayload: received proposal with DEPRECATED AH protocol.
    [vpnd 8273 2012165824]@bbudrgw1[3 Jun 13:13:39] payload_list_destroy: return a list of 1 payload
    [vpnd 8273 2012165824]@bbudrgw1[3 Jun 13:13:39] processPropPayloadList: ignoring proposal 1
    [vpnd 8273 2012165824]@bbudrgw1[3 Jun 13:13:39] payload_list_destroy: return a list of 1 payload
    [vpnd 8273 2012165824]@bbudrgw1[3 Jun 13:13:39] processPropPayloadList: ignoring proposal 1, since last prop was ignored.
    [vpnd 8273 2012165824]@bbudrgw1[3 Jun 13:13:39] 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:

Proposing an unencrypted AH only tunnel is not supported by Check Point.

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

Product: IPSec VPN, SmartView Tracker, SecureClient

Symptoms:

  • SmartView Tracker log shows the "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 the following:

  • Set an older encryption method, such as AES-128 instead of AES-256:

    1. Open SmartDashboard.
    2. From the top menu, select 'Policy' > 'Global Properties'.
    3. From the left menu, select 'Remote Access' > 'VPN - IKE (Phase 1)'.
    4. In the 'Support encryption algorithms' list, select the desired algorithms and clear undesired algorithms.
    5. From the left menu, select 'Remote Access' > 'VPN - IPSEC (Phase 2)'.
    6. Select the required encryption algorithm from the 'Encryption Algorithm' drop-down list.
    7. Click 'OK'.
    8. Install the Security Policy.
    9. Reconnect the remote client.
  • Change the parameter that controls the size of the proposal group to be used by the VPN client to 'large':

    1. Open SmartDashboard.
    2. From the top menu, select 'Policy' > 'Global Properties'.
    3. From the left menu, select 'SmartDashboard Customization' and click the 'Configure...' button.
    4. From the left tree-menu, select 'SecuRemote/SecureClient' > 'IKE/IPSec Settings'.
    5. Change the value of the 'desktop_ike_p2_prop_size' from 'small' to 'large'.
    6. Click 'OK' in both windows.
    7. Install the Security Policy.
    8. Reconnect the remote client.

Scenario 5: Site-to-Site VPN using IKEv2 fails when SecureXL is enabled

Product: IPSec VPN, SecureXL

Symptoms:

  • Site-to-Site VPN using IKEv2 fails.

  • Ikev2.xmll file in $FWDIR/log shows "No Proposal Chosen" in IKEv2.

  • Debug on VPND daemon (per sk89940) shows that Check Point Security Gateway fails to validate the TS-i (Traffic Selector - Initiator) payload upon receiving response from VPN peer:
    [vpnd ...]@...Time] ikeChildSAExchange_i::isPayloadExpected: entering. payload: TS-i.
    [vpnd ...]@...Time] Exchange::validateGeneralPayload: validating payload TS-i..
    [vpnd ...]@...Time] TSPayload::Verify_ipv4: trying to match peer range X.X.X.X
    ... ...
    [vpnd ...]@...Time] TSPayload::Verify_ipv4: matched!!!!
    ... ...
    [vpnd ...]@...Time] TSPayload::Verify_ipv6: trying to match peer range 0: X.X.X.X against 0 policy ranges
    [vpnd ...]@...Time] TSPayload::Verify_ipv6: Could not match traffic selector 1 (<X.X.X.X>)
    [vpnd ...]@...Time] TSPayload::Verify_ipv6: Could not match any selectors
    [vpnd ...]@...Time] TSPayload::Verify: returns true
    ... ...
    [vpnd ...]@...Time] TSPayload::getByConn: Returning empty TS
    [vpnd ...]@...Time] ikeChildSAExchange_i::validateTSiPayload: empty traffic selector.
    [vpnd ...]@...Time] Exchange::processPayloads: problem processing payload no. 4 of type TS-i payload
    [vpnd ...]@...Time] Exchange::processPayloads: processPayloads returning initial status
    [vpnd ...]@...Time] Exchange::setStatus: Changing status from: initial to: failure (final)..
    [vpnd ...]@...Time] Exchange::setLog: Setting log message:
    Peer's message is unacceptable.

  • Issue occurs only when NAT (Manual or Automatic) is used on the encryption domain.

  • Disabling SecureXL resolves the issue.

Cause:

The issue occurs in the "Create Child SA" phase in IKEv2, during traffic selector (TS) validation.

When SecureXL is enabled, IKEv2 fails to Create Child SA, since the wrong Traffic Selectors are being verified.

It is assumed that the connection was already NATed, which is not the case when SecureXL is enabled. As a result, Traffic Selectors validation fails, when compared against the unNATed connection.

Solution:

This problem was fixed. The fix is included in:

 

For other supported versions, Check Point Support can supply a Hotfix.
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 for Gaia/SecurePlatform/IPSO OS:

  1. Hotfix has to be installed on Security Gateway.

    Note: In cluster environment, this procedure must be performed on all members of the cluster.

  2. Transfer the hotfix package to the machine (into some directory, e.g., /some_path_to_fix/).

  3. Unpack the hotfix package:

    [Expert@HostName]# cd /some_path_to_fix/
    [Expert@HostName]# tar -zxvf fw1_wrapper_<HOTFIX_NAME>.tgz

  4. Install the hotfix:

    [Expert@HostName]# ./fw1_wrapper_<HOTFIX_NAME>

    Note: The script will stop all of Check Point services (cpstop) - read the output on the screen.

  5. Reboot the machine.

 

The following workarounds can be tried:

  • Disable SecureXL
  • Attempt to Create Child SA and provide a TS-r (Traffic Selector - Responder) that just contains IP addresses
  • Attempt to Create Child SA and provide a TS-r (Traffic Selector - Responder) and a TS-i (Traffic Selector - Initiator) that both contain protocol and port
  • Delete all IPsec+IKE SAs for a given peer on both sides
  • Make the initiator of the SA be the Check Point VPN Peer (e.g., ping from that peer into Check Point encryption domain)

 

Related solutions:

Scenario 6: Mac OS VPN Clients are unable to connect using SHA-2

Product: Endpoint Security VPN, Endpoint Connect

Symptoms:

  • Mac VPN client is unable to connect and see error: "The user is not defined properly." Negotiation is stopped after first Quick Mode packet.

  • Smart View tracker log: "No Proposal Chosen"
  • Windows VPN Clients are able to connect.

Cause:

SHA-256 (SHA-2) for IPsec (Phase 2) is only supported on Windows releases of Endpoint - not supported for Mac OS.

Solution:

This problem was fixed. The fix is included in:

Check Point recommends to always upgrade to the most recent version (upgrade Endpoint Security).

If you choose not to upgrade, you can use this workaround.

Modify the IPSec (Phase 2) algorithm to SHA-1:

  1. Open the SmartDashboard
  2. Expand Remote Access
  3. Click on VPN - Authentication
  4. Press Edit under Encryption algorithms
  5. Move to IPSEC Security Assosication (Phase 2) tab
  6. Change the Data integrity to SHA-1.

Scenario 7: Site to site with DAIP Gateway fail with "No Proposal Chosen" sent by the central Gateway

Product: IPSec VPN,

Symptoms:

  • Site to site with DAIP Gateway fail with "No Proposal Chosen" sent by the central Gateway
  • SHA384 is defined as Data Integrity for Main Mode.
  • One of the peers defined as Dynamic IP Gateway and installed with R77.30 or lower.

Cause:

This is a limitation for DAIP Gateways which rely the Main Mode encryption configuration by Global Properties -> remote Access -> VPN - Authentication and Encryption, there is not an option to use SHA384.

Solution:

This problem was fixed. The fix is included in:

Check Point recommends to always upgrade to the most recent version

 

As a workaround, change Data Integrity to SHA256 or SHA1.


Instructions for R77.30 and lower:
  1. Go to IPSec VPN tab, at the left pane please click The Communities and open the relevant community.

  2. Go to Encryption tab, open the Custom Encryption to define the Data Integrity parameter.

Instructions for R80.10:
  1. Open the SmartConsole, refer to the right pane to Object Categories.

  2. Click VPN Communities and then the relevant community contains the relevant Gateways.

  3. Go to Encryption tab and define the Data Integrity parameter.



Applies To:
  • The following solutions were merged into sk114834:
    sk105218, sk88900, sk106431, sk33857, sk110133, sk113250, sk122293

Give us Feedback
Please rate this document
[1=Worst,5=Best]
Comment