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:

• Jumbo Hotfix Accumulator for R77.30 - since Take_189
• Check Point R80.10

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.

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 R77

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.

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.

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.

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:

• Jumbo Hotfix Accumulator for R77.30 - since Take_145
• Jumbo Hotfix Accumulator for R77.20 - since Take_192

 

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:

• sk89940 - How to debug VPND daemon
• sk33327 - How to generate a valid VPN debug, IKE debug and FW Monitor?

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:

• Enterprise Endpoint Security R77.30.02/E80.64

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.

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 R80.10

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.

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