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
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
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:
Hotfix has to be installed on Security Gateway.
Note: In cluster environment, this procedure must be performed on all members of the cluster.
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:
Transfer the hotfix package to the machine (into some directory, e.g., /some_path_to_fix/).
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.
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_Addressnot 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_Addressnot in DAIP range
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".
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.
SmartView Tracker log shows the "No proposal chosen" error, even though the VPN connection is actually successful and traffic passes between VPN peers.
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:
Open SmartDashboard.
From the top menu, select 'Policy' > 'Global Properties'.
From the left menu, select 'Remote Access' > 'VPN - IKE (Phase 1)'.
In the 'Support encryption algorithms' list, select the desired algorithms and clear undesired algorithms.
From the left menu, select 'Remote Access' > 'VPN - IPSEC (Phase 2)'.
Select the required encryption algorithm from the 'Encryption Algorithm' drop-down list.
Click 'OK'.
Install the Security Policy.
Reconnect the remote client.
Change the parameter that controls the size of the proposal group to be used by the VPN client to 'large':
Open SmartDashboard.
From the top menu, select 'Policy' > 'Global Properties'.
From the left menu, select 'SmartDashboard Customization' and click the 'Configure...' button.
From the left tree-menu, select 'SecuRemote/SecureClient' > 'IKE/IPSec Settings'.
Change the value of the 'desktop_ike_p2_prop_size' from 'small' to 'large'.
Click 'OK' in both windows.
Install the Security Policy.
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.
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.
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:
Hotfix has to be installed on Security Gateway.
Note: In cluster environment, this procedure must be performed on all members of the cluster.
Transfer the hotfix package to the machine (into some directory, e.g., /some_path_to_fix/).
Unpack the hotfix package:
[Expert@HostName]# cd /some_path_to_fix/ [Expert@HostName]# tar -zxvf fw1_wrapper_<HOTFIX_NAME>.tgz
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.
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)
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.