> Source: [sk108600](https://support.checkpoint.com/results/sk/sk108600) # sk108600 - VPN Site-to-Site with 3rd party | Property | Value | |----------|-------| | Solution ID | sk108600 | | Date Created | 2015-11-09 | | Last Modified | 2026-07-15 | | Technical Level | General | | Products | Security Gateway | | Versions | R82.10, R82, R81.20, R81.10 (EOS), R81 (EOS) | ## Solution **Table of Contents:** * Introduction * Scenario 1 - Wrong IPsec IDs are negotiated during IKE Quick Mode * Scenario 2 - IKE Main Mode negotiation fails on 3rd party peer because it expects FQDN as ID * Scenario 3 - Implied inclusion of Check Point Security Gateway's / 3rd party VPN Peer's interfaces * Scenario 4 - Difference in implementations of tunnel renewal between vendors * Scenario 5 - Permanent Tunnels (Dead Peer Detection) issues * Scenario 6 - 3rd party VPN peer proposes Phase 2 lifetime in kilobytes * Scenario 7 - "Quick Mode Received Notification from Peer: invalid id information" error * Scenario 8 - Configuring Enhanced Link Selection for Redundant and Load-Sharing VPN Connections Show the Entire Article Introduction {#Introduction} ---------------------------- This article describes configurations/issues related to VPN Site-to-Site with 3rd party vendors. **Note for Locally Managed Quantum Spark Appliances:** The *crypt.def* file is located in: 1. */pfrm2.0/config2/fw1/lib/crypt.def* 2. */pfrm2.0/opt/fw1/lib/crypt.def* After you make the changes, you must run the *fw_configload* command (or reboot the appliance). **Note: The following scenarios are relevant for both Simplified and Traditional modes.** Scenario 1 - Wrong IPsec IDs are negotiated during IKE Quick Mode {#Scenario 1} ------------------------------------------------------------------------------- ### Symptoms: * "`Invalid ID information`" log in SmartView Tracker when the Security Gateway initiates a Quick Mode. * "`No valid SA`" logs in SmartView Tracker when creating IPsec VPN tunnel with an interoperable device. * Remote Access Client cannot access internal resources over the Site-to-Site tunnel with 3rd party VPN peer. * VPN tunnel can be initiated from 3rd party side to the Check Point Security Gateway side, but not from Check Point side to 3rd party side. Show / Hide solution ### Explanation: {#Toggle_Scenario_1} * During IKE Quick Mode negotiation, the IP addresses, which define the VPN tunnel (also known as IPSec IDs, or traffic selectors) are negotiated. The IP addresses can be a set of discrete IP addresses, or a subnet. When negotiating a VPN tunnel between Check Point Security Gateway and certain 3rd-party devices, IKE Quick Mode may fail, if the subnets are defined differently on each end of the VPN tunnel. One reason is that Check Point Security Gateway dynamically supernets subnets to reduce the amount of SA overhead. ### Solution: **Important - Starting in R80.20, you can disable supernetting behavior with 3rd party VPN devices, per specific community.** That way you can migrate to a non-supernetting environment gradually, community by community. This process requires also configuration changes on the 3rd party peers as well. **Refer to [sk144094 - VPN tunnels with 3rd party peers fail because of mismatched IDs](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk144094).** **Note:** The global parameter *ike_enable_supernet* determined supernetting behavior for all 3rd party devices. To disable supernetting per specific community, first set the value of the *ike_enable_supernet* parameter to "true" via the GuiDBedit tool. Supernetting will be first enabled for ALL 3rd party peers. Then, using GuiDBedit, per selected community object, change the *ike_p2_enable_supernet_from_R80.20* parameter from "by_global" to "false". That way, the supernet will be disabled for 3rd party peers that are members of that specific community. Once all relevant communities (with 3rd party objects) have been migrated to non-supernetting behavior, you can set the global parameter *ike_enable_supernet* to "false", and on all relevant communities, set *ike_p2_enable_supernet_from_R80.20* to "by_global". **Important -** With The improvement, you can disable "supernetting" **only**for 3rd party VPN devices, but keep "supernetting" enabled with Check Point Security Gateways. In addition, in the current behavior with externally managed Check Point devices with "supernetting" disabled, IPsec SA is created per host, but not per sub-net. This improvement fixes this. **In R80.20 and lower:** **Note:** in this solution the supernetting is disabled for all devices. **In other words, if you have two communities communicating with a 3rd party, and define custom rules in the *user.def* file for one of the VPNs, the supernetting will be disabled for the other community, as well.** Define the IP ranges that the Check Point Security Gateway should negotiate with this 3rd party peer in the "***subnet_for_range_and_peer*** " table in the relevant "***user.def***" file on the Security Management Server / Domain Management Server. The "***subnet_for_range_and_peer***" table is designed to force Check Point Security Gateway to negotiate IPsec SAs using a specific subnet mask for a given IP address range: > > ``` > subnet_for_range_and_peer = { > , > , > ... ... ... > > }; > ``` **Notes:** * The location of relevant *user.def* file depends on the version of the Check Point Security Gateway and the version of Management Server. Refer to these solutions: * [sk98239 - Location of 'user.def' files on Security Management Server](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk98239) * [sk30919 - Creating customized rules for Check Point Security Gateway - 'user.def' file](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk30919) * Avoid defining overlapping ranges in the table. Define the ranges as they are defined on the peer. For example, if there are two separate subnets defined on the peer - 10.0.1.0/24 and 10.0.2.0/24, then do *not* "combine" them into supernet 10.0.1.0/23. * The list of subnets can include both the subnets in the encryption domain of the 3rd party peer and the subnets in the encryption domain of the local Check Point Security Gateway. * The peer IP address is always the IP address of remote peer in every entry in the list. * The relevant subnets to enter are the ones that the Check Point Security Gateway supernets together - either subnets in its own encryption domain, or in the 3rd party peer's encryption domain (an entry for each subnet). * To see the contents of this table (in Hex format) on Check Point Security Gateway, run: *\[Expert@HostName:0\]# fw tab -t subnet_for_range_and_peer* * This feature is supported only for Check Point Security Gateways *NGX R60* and higher. **Procedure:** 1. Open the relevant "*user.def* " file (refer to [sk98239](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk98239)) in a plain-text editor (Vi on Unix-based OS ; Notepad/Notepad++ on Windows OS) and verify that it contains the following lines: > ``` > #ifndef __user_def__ > #define __user_def__ > > // > // User defined INSPECT code > // > > #endif /* __user_def__ */ > ``` 2. Backup the relevant "*user.def* " file (refer to [sk98239](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk98239)) on Security Management Server / Domain Management Server. 3. Configure the subnet used in the Quick Mode IPsec SAs negotiation: ***Example 1*:** : ``` #ifndef __user_def__ #define __user_def__ // // User defined INSPECT code // subnet_for_range_and_peer = { <192.168.10.20, 10.10.0.1, 10.10.0.254; 255.255.255.0>, <192.168.20.20, 10.10.0.1, 10.10.255.254; 255.255.0.0> }; #endif /* __user_def__ */ ``` In this example, the configuration would work in the following way: * For the VPN peer 192.168.10.20, the network IP used in the IPsec SA would be 10.10.0.0/24 * For the VPN peer 192.168.20.20, the network IP used in the IPsec SA would be 10.10.0.0/16 ***Example 2*:** : ``` #ifndef __user_def__ #define __user_def__ // // User defined INSPECT code // subnet_for_range_and_peer = { <192.168.20.20, 10.10.44.6, 10.10.44.6; 255.255.255.255> }; #endif /* __user_def__ */ ``` In this example, the configuration would work in the following way: * Only connections from Host 10.10.44.6 behind the gateway to the network behind VPN peer 192.168.20.20 would be negotiated

1. Save the changes in the "*user.def* " file and exit from the editor. 2. Connect with SmartConsole to Security Management Server / Domain Management Server. 3. Install the security policy onto relevant Security Gateway / Cluster. 4. Check the contents of this table (in Hex format) on Check Point Security Gateway / each Cluster member: ***\[Expert@HostName:0\]# fw tab -t subnet_for_range_and_peer*** Related solutions: * [sk98239 - Location of 'user.def' files on Security Management Server](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk98239) * [sk30919 - Creating customized rules for Check Point Security Gateway - 'user.def' file](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk30919) Scenario 2 - IKE Main Mode negotiation fails on 3rd party peer because it expects FQDN as ID {#Scenario 2} ---------------------------------------------------------------------------------------------------------- ### Symptoms: * Site-to-Site VPN connection between Check Point Security Gateway and 3rd party VPN gateway fails. * *$FWDIR/log/ike.elg* under debug (per [sk180488](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk180488)) on Check Point Security Gateway shows: `(AUTHENTICATION-FAILED) in MM packet 5 or 6` * *$FWDIR/log/ike.elg* under debug shows "INVALID-ID-INFORMATION" payload after Main Mode packet 5. Show / Hide solution ### Explanation: {#Toggle_Scenario_2} * The error message is received from the 3rd party peer because it does not trust the IKE ID sent to it by Check Point Security. * This is relevant to IKEv2 ID. ### Solution: * **Overview** The purpose of the IKE ID Type exchanged during the IKE Main Mode (MM) negotiation (Packet 5 and Packet 6) is to provide an ID, based on which the remote peer searches for the local peer in its database. The ID Type can be set to anything, such as an IP address, FQDN, e-mail address, etc. **The ID Type is not necessary for IKE Main Mode (MM) negotiation between Check Point Security Gateways. However, it is necessary for most 3rd party VPN gateways. It is important to make sure both sides authenticate using the same ID Type and ID values.** By default, Check Point Security Gateways send ID Type set to IP address. Moreover, the Internal CA VPN certificate is created (by default) with the "Subject Alternate Names" field in the VPN properties of the Security Gateway object is set to the IP address of the Security Gateway. *Examples of IKE Main Mode Packet 5*: * Packet 5 with ID Type set to IP address (the default for Check Point Security Gateway): ``` ID Payload Next Payload: Certificate Reserved: 0 Length: 00 0c (12) ID type: ID_IPV4_ADDR Service type: Not specified (0) Service port: Not specified (0) ID Data: ac 08 00 02 (172.8.0.2) ``` * Packet 5 with ID Type set to FQDN: ``` ID Payload Next Payload: Certificate Reserved: 0 Length: 00 15 (21) ID type: ID_FQDN Service type: UDP (11) Service port: 01 f4 (500) ID Data: 52 32 2e 61 73 67 6c 61 62 2e 6c 6f 63 ID as string: mygateway.company.com ``` * **If you do not want to use FQDN (Only for IKEv1) (Procedure for R80.20 and higher)** **Note: Since R80.30, IKEv2 is also supported.** 1. Determine the IP address as IKE MM-ID dynamically, according to the OS routing. 2. Before sending the relevant IKE packet, consult the OS routing table to determine on which outbound interface the packet is going to be be delivered, and set the IKE MM-ID to be the address of that interface. **To enable IKE MM-ID based on routing on the Security Gateway:** 1. Run: *ckp_regedit -a SOFTWARE/CheckPoint/VPN1 BestRoutingSenderIP True* 2. Run: *cpstop ; cpstart* **To disable IKE MM-ID based on routing on the Security Gateway:** 1. Run: *ckp_regedit -a SOFTWARE/CheckPoint/VPN1 BestRoutingSenderIP False* 2. Run: *cpstop ; cpstart* **To check the status of IKE MM-ID based on routing on the Security Gateway:** Run: *ckp_regedit -p SOFTWARE\\\\CheckPoint\\\\VPN1 \| grep BestRoutingSenderIP* * **Notes** * The FQDN solution below is relevant for IKEv1, and for IKEv2 in R80.10 and higher. * The procedure below has been verified for IKEv1 (for both Main-Mode and Aggressive-Mode), when authenticating with signatures (certificates). * The procedure below has been verified for IKEv1 (only for Aggressive-Mode), when authenticating with signatures Pre-Shared Key (according to RFC-2409). * When authenticating with signatures (certificates) on IKEv2, refer to option 1 below. * When authenticating with Pre-Shared Key on IKEv2, refer to option 2 below. * Quantum Spark appliances support this feature only in R81.10.X versions. * **Procedure for for IKEv1 and R80.10 and higher (for IKEv2)** * (**Option 1** ) When working with certificates, make sure that the "Subject Alternate Names" field in the VPN properties of the Security Gateway object is set to FQDN. If not, recreate the certificate and set the "Subject Alternate Names" field to FQDN (in SmartConsole, open the Security Gateway object - go to IPSec VPN pane - click on "Renew" button). * (**Option 2**) Configure the required environment variables on Security Gateway so it would set the IKE ID Type to the defined FQDN: * Show / Hide instructions for Security Gateway running on Gaia / SecurePlatform / IPSO OS 1. In the ***$CPDIR/tmp/.CPprofile.sh*** script: Add these lines at the end of the relevant file: ***CP_FQDN_ID=*"Desired_FQDN"* ; export CP_FQDN_ID*** ***CP_ACCEPT_FQDN=YES ; export CP_ACCEPT_FQDN*** 2. In the ***$CPDIR/tmp/.CPprofile.csh*** script: Add these lines at the end of the relevant file: ***setenv CP_FQDN_ID *"Desired_FQDN"**** ***setenv CP_ACCEPT_FQDN *YES**** 3. Restart all Check Point services: ***\[Expert@HostName\]# cpstop ; cpstart*** **Important Note:** If you are not able to restart the Check Point services at this time, then run these commands: * In Bash shell (default shell for Expert mode): ***\[Expert@HostName\]# export CP_FQDN_ID="Desired_FQDN" \[Expert@HostName\]# export CP_ACCEPT_FQDN=YES*** * In Csh shell: ***\[admin@HostName \~\]# setenv CP_FQDN_ID "Desired_FQDN" \[admin@HostName \~\]# setenv CP_ACCEPT_FQDN YES*** **Notes:** * To unset these environment variables permanently, remove them from the above shell scripts and restart Check Point services with "*cpstop;cpstart* " commands. * To unset these environment variables on-the-fly (in the current shell session): * In Bash shell (default shell for Expert mode): * *\[Expert@HostName\]# unset CP_FQDN_ID \[Expert@HostName\]# echo $CP_FQDN_ID* * *\[Expert@HostName\]# unset CP_ACCEPT_FQDN \[Expert@HostName\]# echo $CP_ACCEPT_FQDN*

* In Csh shell: * *\[admin@HostName \~\]# unsetenv CP_FQDN_ID \[admin@HostName \~\]# echo $CP_FQDN_ID* * *\[admin@HostName \~\]# unsetenv CP_ACCEPT_FQDN \[admin@HostName \~\]# echo $CP_ACCEPT_FQDN*

* Show / Hide instructions for Security Gateway running on Windows OS 1. Start menu - Run... - ***"%WINDIR%\\system32\\rundll32.exe" sysdm.cpl,EditEnvironmentVariables*** - click on OK Alternatively: 1. Desktop - right-click on the "*My Computer* " icon - click on "*Properties*" 2. Windows Vista/7/2012: In the left pane, click on "*Advanced system settings*". 3. Go to "*Advanced*" tab. 4. At the bottom, click on "*Environment Variables...*" button.

2. Under "*System variables* " - click on "*New...*" * name: ***CP_FQDN_ID*** * value: ***Desired_FQDN*** * and click "*OK* " to close the "*New System Variable*" window.

3. Under "*System variables* " - click on "*New...*" * name: ***CP_ACCEPT_FQDN*** * value: ***YES*** * and click "*OK* " to close the "*New System Variable*" window.

4. Click on "*OK* " to close the "*Environment Variables* " window. 5. Reboot the machine. **Notes:** * To unset these environment variables permanently, under "*System Variables* " click on these variable and click on "*Delete* " and reboot the machine. * To unset these environment variables on-the-fly (in the current shell session): Run these commands in Windows Command Prompt: *C:\\\> set CP_FQDN_ID=* *C:\\\> set CP_ACCEPT_FQDN=*

* For either option 1 or 2, reboot the Security Gateway. * If you use option 2, then verify that these environment variables were applied on Security Gateway: * For Security Gateway running on Gaia / SecurePlatform / IPSO OS: * ***\[Expert@HostName\]# echo $CP_FQDN_ID*** Output should show "``" * ***\[Expert@HostName\]# echo $CP_ACCEPT_FQDN*** Output should show "`YES`"

* For Security Gateway running on Windows OS: Run these commands in Windows Command Prompt: * ***C:\\\> set \| findstr CP_FQDN_ID*** Output should show "`CP_FQDN_ID=`" * ***C:\\\> set \| findstr CP_ACCEPT_FQDN*** Output should show "`CP_ACCEPT_FQDN=YES`"

* For either option 1 or 2, to verify that the Check Point Security Gateway sets the IKE ID Type to the defined FQDN: 1. Start the VPN debug on Check Point Security Gateway per [sk180488](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk180488) (the "vpn debug" command). 2. Kill all traffic over the VPN with 3rd party VPN Gateway. This will include stopping all continuous traffic across the VPN tunnel. 3. Clear the IKE keys on the 3rd party VPN Gateway. **Important Note:** If clearing the IKE keys is *not* possible, then ***skip*** to **Step H** . 4. Launch the *TunnelUtil* tool, which is used to control VPN tunnels: ***\[Expert@HostName\]# vpn tu*** 5. Select the option "***Delete all IPsec+IKE SAs for a given peer (GW)*** ". 6. Enter the IP address of the 3rd party VPN Gateway. 7. Exit from the *TunnelUtil* tool. 8. Initiate a VPN tunnel from Check Point Security Gateway to 3rd party VPN Gateway. 9. Wait for the VPN tunnel to be established. 10. Stop the VPN debug on Check Point Security Gateway per [sk180488](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk180488) (the "vpn debug" command). 11. Open the *$FWDIR/log/ike.elg* file on Check Point Security Gateway and check the value of ***ID type***.
**Note:** In case of tunnel with IKEv2, open the $FWDIR/log/ikev2.xmll file. Scenario 3 - Implied inclusion of Check Point Security Gateway's / 3rd party VPN Peer's interfaces {#Scenario 3} ---------------------------------------------------------------------------------------------------------------- ### Symptoms: * Traffic initiated from external interfaces of the 3rd party VPN Peer to external interface of the Check Point Security Gateway is dropped with "*Clear text packet should be encrypted*" log. * Traffic to the external IP address of the 3rd party gateway fails. * The 3rd party peer sends *INVALID-ID* notifications, because the Check Point Security Gateway is proposing a VPN tunnel for the external IP addresses. Show / Hide solution ### Explanation: {#Toggle_Scenario_3} * 3rd party devices may not include their external IP addresses in their VPN domain as opposed to Check Point Security Gateway. This may cause 3rd party VPN peers to send "delete" for Phase 1 and cause tunnel interruptions. ### Solution: Special macro ***NON_VPN_TRAFFIC_RULES*** (configured in the relevant "***crypt.def*** " / "***user.def***" file on the Security Management Server / Domain Management Server) will prevent traffic entering a VPN tunnel, if the source and destination matches the configured rules. For example, all web traffic to all public IP addresses needs to be sent through a VPN tunnel, but only for a subset of the IP addresses in the encryption domain. **Notes:** * For Security Gateways *R70* and higher, the macro is configured in the relevant "***crypt.def*** " file. The location of relevant *crypt.def* file depends on the version of the Check Point Security Gateway and the version of Management Server. Refer to this solution: * [sk98241 - Location of 'crypt.def' files on Security Management Server](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk98241) * For Security Gateways *R65* , the macro is configured in the relevant "***user.def*** " file. The location of relevant *user.def* file depends on the version of the Check Point Security Gateway and the version of Management Server. Refer to these solutions: * [sk98239 - Location of 'user.def' files on Security Management Server](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk98239) * [sk30919 - Creating customized rules for Check Point Security Gateway - 'user.def' file](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk30919) * This feature is supported for Check Point Security Gateway *NGX R65* and higher. **Procedure:** * Show / Hide the procedure for R76 and higher versions 1. Backup the relevant "*crypt.def* " file (refer to [sk98241](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk98241)) on Security Management Server / Domain Management Server. 2. Open the relevant "*crypt.def* " file in a plain-text editor (Vi on Unix-based OS ; Notepad/Notepad++ on Windows OS). 3. Find this line: > *#define NON_VPN_TRAFFIC_RULES* You should see these three lines: > > ``` > #ifndef NON_VPN_TRAFFIC_RULES > #define NON_VPN_TRAFFIC_RULES 0 > #endif > ``` 4. Modify these three lines to: * To exclude only IPv4 address: > > ``` > #ifndef IPV6_FLAVOR > #define NON_VPN_TRAFFIC_RULES (dst=Destination_IPv4_address,dport=Destination_Port) > #else > #define NON_VPN_TRAFFIC_RULES 0 > #endif > ``` > > The *Destination_IPv4_address* is the IPv4 address of the remote peer, which should be excluded from the Gateway's remote encryption domain. * To exclude multiple IPv4 addresses: > > ``` > #ifndef IPV6_FLAVOR > #define NON_VPN_TRAFFIC_RULES (dst=Destination_IPv4_address_1 or dst=Destination_IPv4_address_2) > #else > #define NON_VPN_TRAFFIC_RULES 0 > #endif > ``` > > The *Destination_IPv4_address* is the IPv4 address of the remote peer, which should be excluded from the Gateway's remote encryption domain. * To exclude only IPv6 address: > > ``` > #ifndef IPV6_FLAVOR > #define NON_VPN_TRAFFIC_RULES 0 > #else > #define NON_VPN_TRAFFIC_RULES (dst=Destination_IPv6_address,dport=Destination_Port) > #endif > ``` > > The *Destination_IPv6_address* is the IPv6 address of the remote peer, which should be excluded from the Gateway's remote encryption domain. * To exclude both IPv4 address and IPv6 address: > > ``` > #ifndef IPV6_FLAVOR > #define NON_VPN_TRAFFIC_RULES (dst=Destination_IPv4_address,dport=Destination_Port) > #else > #define NON_VPN_TRAFFIC_RULES (dst=Destination_IPv6_address,dport=Destination_Port) > #endif > ``` > > The *Destination_IPv4_address* is the IPv4 address of the remote peer, which should be excluded from the Gateway's remote encryption domain. > The *Destination_IPv6_address* is the IPv6 address of the remote peer, which should be excluded from the Gateway's remote encryption domain. 5. Save the changes in the "*crypt.def* " file and exit from the editor. 6. Connect with SmartConsole to Security Management Server / Domain Management Server. 7. Install the security policy onto relevant Security Gateway / Cluster. 8. Verify that there are proper NAT rules for Hide-NATing of the internal source addresses when accessing the remote peer address in clear from the VPN site (e.g., *Src=internal net* , Dst=*IP_Address* ---\> *Src=Hide* behind gateway external address, Dst=original)

* Show / Hide the procedure for R70 / R71 / R75 versions 1. Backup the relevant "*crypt.def* " file (refer to [sk98241](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk98241)) on Security Management Server / Domain Management Server. 2. Open the relevant "*crypt.def* " file in a plain-text editor (Vi on Unix-based OS ; Notepad/Notepad++ on Windows OS). 3. Find this line: > *#define NON_VPN_TRAFFIC_RULES* You should see the following lines: > > ``` > > #ifndef NON_VPN_TRAFFIC_RULES > #define NON_VPN_TRAFFIC_RULES 0 > #endif > ``` 4. Modify these lines to: > ``` > > #ifndef NON_VPN_TRAFFIC_RULES > #define NON_VPN_TRAFFIC_RULES (dst=Destination_IP_address) > #endif > ``` > > The *Destination_IP_address* is the IP address of the remote peer, which should be excluded from the Gateway's remote encryption domain. 5. Save the changes in the "*crypt.def* " file and exit from the editor. 6. Connect with SmartConsole to Security Management Server / Domain Management Server. 7. Install the security policy onto relevant Security Gateway / Cluster. 8. Verify that there are proper NAT rules for Hide-NATing of the internal source addresses when accessing the remote peer address in clear from the VPN site (e.g., *Src=internal net* , Dst=*IP_Address* ---\> *Src=Hide* behind gateway external address, Dst=original)

* Show / Hide the procedure for R65 versions 1. Backup the relevant "*user.def* " file (refer to [sk98239](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk98239)) on Security Management Server / Domain Management Server. 2. Open the relevant "*user.def* " file in a plain-text editor (Vi on Unix-based OS ; Notepad/Notepad++ on Windows OS). 3. **Add** the following line at the end of the file: > ``` > #define NON_VPN_TRAFFIC_RULES (dst=Destination_IP_address) > ``` > > The *Destination_IP_address* is the IP address of the remote peer, which should be excluded from the Gateway's remote encryption domain. 4. Save the changes in the "*user.def* " file and exit from the editor. 5. Connect with SmartConsole to Security Management Server / Domain Management Server. 6. Install the security policy onto relevant Security Gateway / Cluster. 7. Verify that there are proper NAT rules for Hide-NATing of the internal source addresses when accessing the remote peer address in clear from the VPN site (e.g., *Src=internal net* , Dst=*IP_Address* ---\> *Src=Hide* behind gateway external address, Dst=original) Related solutions: * [sk98241 - Location of 'crypt.def' files on Management Server](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk98241) * [sk98239 - Location of 'user.def' files on Security Management Server](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk98239) Scenario 4 - Difference in implementations of tunnel renewal between vendors {#Scenario 4} ------------------------------------------------------------------------------------------ ### Symptoms: * Intermittent drops of VPN traffic between Check Point Security Gateway and 3rd party VPN peer (SmartView Tracker logs might show "*encryption fail reason: Packet is dropped because an IPsec SA associated with the SPI on the received IPsec packet could not be found*"). * "*vpn_ipsec_decrypt Reason: decryption failure: Could not get SAs from packet*" error in VPN kernel debug. * IKE debug shows that 3rd party VPN peer sends an SPI "delete" after successful Phase1/Phase2 key negotiation. * VPN tunnel becomes unstable after an "*IKE: Send Delete*" packet is sent. * Debug of VPND daemon (per [sk89940](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk89940)) might show "*valid isakmp sa was not found*". Show / Hide solution ### Explanation: {#Toggle_Scenario_4} * Check Point Security Gateway deletes all Phase2 keys for a specific Phase1 SA after a Phase1 renegotiation. VPN solutions from other vendors continue to use the same Phase2 keys until their normal expiration time. This causes something like a race condition where the VPN tunnel will drop for about 10-15 minutes until the two VPN peers can get SAs back in sync and the VPN tunnel negotiations are completed. ### Solution: Show / Hide instructions To disable deletion of IPsec SAs on IKE SA Delete notification, you can use the kernel parameter - *ike_keep_child_sa_interop_devices* . By default, the value of this configuration parameter is set to "true", in most cases (by default, IPsec SAs will not be deleted on IKE SA Delete notification, which is the recommended configuration). It might be set to "false", by default, in some cases where the Management server has been upgraded from a lower version. This configuration affects only 3rd party VPN peers. To revert to the old behavior where IPsec SAs are deleted upon IKE SA Delete notification (**not recommended**): 1. Connect with SmartConsole to Security Management Server / Domain Management Server. 2. Go to ***File*** menu - click on ***Database Revision Control...*** - create a revision snapshot. Note: Database Revision Control is not supported for VSX objects ([sk65420](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk65420)). 3. Close all SmartConsole windows (SmartConsole, SmartView Tracker, SmartView Monitor, etc.). 4. Connect with [GuiDBedit Tool](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk13009) to Security Management Server / Domain Management Server. 5. Press CTRL+F (or go to ***Search*** menu - ***Find*** ) - paste ***ike_keep_child_sa_interop_devices*** - click on ***Find Next*** . 6. In the lower pane, right-click on the ***ike_keep_child_sa_interop_devices*** - select ***Edit...*** - select "***false*** " - click on ***OK*** . 7. Save the changes: go to ***File*** menu - click on ***Save All*** . 8. Close the GuiDBedit Tool. 9. Connect with SmartConsole to Security Management Server / Domain Management Server. 10. Install the policy onto the relevant locally managed Security Gateway / Cluster object. **Note:** In case the IPsec SAs are deleted when ***ike_keep_child_sa_interop_devices*** is set to ***"true"***: [Contact Check Point Support](http://www.checkpoint.com/services/contact/index.html) to get a Hotfix for this issue (ID 02035430). 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](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk92739) files from the Security Management and Security Gateways involved in the case. This fix is already included in: * [Check Point R80.10](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk111841) * [Jumbo Hotfix Accumulator for R77.30](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk106162) - since *Take_184*

**Related Solution:** [sk176957 - IKEV2 Site to Site tunnel from Check Point to 3rd party is randomly dropped with "Invalid SPI" error](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk176957). Scenario 5 - Permanent Tunnels (Dead Peer Detection) issues {#Scenario 5} ------------------------------------------------------------------------- ### Symptoms: * Permanent Tunnel feature is configured with a 3rd party VPN (also known as Interoperable Device), but SmartView Monitor shows this Permanent Tunnel as "Down" even though the tunnel is actually up. * During 1st / 2nd packets, DPD Vendor ID payload is not sent (although it should be per RFC 3706). * Dead Peer Detection (DPD) works correctly during Main Mode. Show / Hide solution ### Explanation: {#Toggle_Scenario_5} * Check Point uses "Tunnel Test" (Check Point proprietary) packets to check the state of a permanent tunnel. 3rd party VPN solutions (Interoperable Devices) do not support these packets and do not respond. As a result, Permanent Tunnels configured with 3rd party VPN peers will be reported as "Down" in SmartView Monitor. ### Solution: **Notes:** * In **R81.20 and higher** versions, the default value of the "tunnel_keep_alive_method" in 3rd party objects is DPD. An upgrade from a previous version to R81.20 and higher changes this field for existing 3rd party objects as well. (3rd party objects whose "tunnel_keep_alive_method" field is set to passive or DPD, will not be affected by this change.) **Important:** There are several vendors that are unable to initiate a tunnel (such as AWS). In the case, where traffic is generated only from the remote side, the tunnel will be down. To prevent this, you can use either 'Tunnel Test' as the Tunnel "Keep alive" method, or use any other "Keep alive" networking monitoring tool (ICMP, IP SLA, etc). * Check Point does not support the DPD monitoring configuration "`tunnel_keepalive_method = passive`" for VPN tunnel with X-Series chassis. Users must configure using the DPD monitoring as "`tunnel_keepalive_method = dpd`". In versions **R81.10 and lower**, Dead Peer Detection (DPD) can be enabled in two modes on Check Point Security Gateway: |--------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | DPD Mode | Configuration Steps | | *DPD responder mode* | Check Point Security Gateway sends the IKEv1 DPD Vendor ID to VPN peers, from which the DPD Vendor ID has been received. * To enable DPD responder mode: 1. Connect to command line on the involved Check Point Security Gateway / each cluster member. 2. Log in to Expert mode. 3. Backup the Check Point Registry: ***\[Expert@HostName:0\]# cp -v $CPDIR/registry/HKLM_registry.data $CPDIR/registry/HKLM_registry.data_ORIGINAL*** 4. Add the global attribute *forceSendDPDPayload* to Registry and set its value to 1 (one): ***\[Expert@HostName:0\]# ckp_regedit -a SOFTWARE/CheckPoint/VPN1 forceSendDPDPayload -n 1*** 5. Verify that the global attribute *forceSendDPDPayload* was added to the Registry: * Either with "*ckp_regedit*" command: ***\[Expert@HostName:0\]# ckp_regedit -p SOFTWARE/CheckPoint/VPN1 forceSendDPDPayload*** Output should be: *SOFTWARE/CheckPoint/VPN1 : { CurrentVersion=\[s\]6.0 **forceSendDPDPayload=\[n\]1** }* * Or with "*grep*" command: ***\[Expert@HostName:0\]# grep forceSendDPDPayload $CPDIR/registry/HKLM_registry.data*** Output should be:
*:forceSendDPDPayload ("**\[4\]1**")* 6. Restart Check Point services: **Important Note:** In cluster, this will cause fail-over. ***\[Expert@HostName:0\]# cpstop ; cpstart***

* To disable DPD responder mode: 1. Connect to command line on the involved Check Point Security Gateway / each cluster member. 2. Log in to Expert mode. 3. Backup the Check Point Registry: ***\[Expert@HostName:0\]# cp -v $CPDIR/registry/HKLM_registry.data $CPDIR/registry/HKLM_registry.data_ORIGINAL*** 4. Delete the global attribute *forceSendDPDPayload* from the Registry: ***\[Expert@HostName:0\]# ckp_regedit -d SOFTWARE/CheckPoint/VPN1 forceSendDPDPayload -n 0*** 5. Verify that the global attribute *forceSendDPDPayload* was deleted from the Registry: * Either with "*ckp_regedit*" command: ***\[Expert@HostName:0\]# ckp_regedit -p SOFTWARE/CheckPoint/VPN1 forceSendDPDPayload*** Output should be: *SOFTWARE/CheckPoint/VPN1 : { CurrentVersion=\[s\]6.0 }* * Or with "*grep*" command: ***\[Expert@HostName:0\]# grep forceSendDPDPayload $CPDIR/registry/HKLM_registry.data*** There should not be any output.

6. Restart Check Point services: **Important Note:** In cluster, this will cause fail-over. ***\[Expert@HostName:0\]# cpstop ; cpstart*** | | *DPD responder mode* | **Note:** In some cases, the Check Point gateway deletes IKE SAs. Since the DPD mechanism is based on IKE SA keys, the peer, mostly a 3rd Party gateway, sends DPD requests without response. Therefore, the remote peer can conclude that the Check Point gateway is down and delete the IKE and IPsec keys. If traffic is initiated by the Check Point gateway and IPsec keys were removed from the remote peer, encrypted traffic will be dropped by the remote peer. In order to suppress this problem the `keep_IKE_SAs` property should be enabled. This property is available under Global Properties -\> SmartConsole Customization -\> Advanced Configuration -\> VPN advanced properties -\> VPN IKE properties. | | *Permanent Tunnel based on DPD mode* | DPD can be used by the Check Point gateway in order to monitor remote peers with the Permanent Tunnel feature. All related behavior and configurations of Permanent Tunnel are supported. To configure DPD for a Permanent Tunnel, the Permanent Tunnel should be configured in the VPN community. Once the Permanent Tunnel is enabled, the Permanent Tunnel mode should be configured. For more information, refer to [R82.10 Site to Site VPN Administration Guide](https://sc1.checkpoint.com/documents/R82.10/WebAdminGuides/EN/CP_R82.10_SitetoSiteVPN_AdminGuide/Default.htm) \> Tunnel Management. To enable the DPD monitoring, the value of property ***tunnel_keepalive_method*** should be configured for *each* VPN gateway in the VPN community, which should be monitored with DPD - including 3rd party gateway (there is no possibility to configure different monitor mechanisms for the same gateway): 1. Connect with SmartConsole to Security Management Server / Domain Management Server. 2. Go to ***File*** menu - click on ***Database Revision Control...*** - create a revision snapshot.. Note: Database Revision Control is not supported for VSX objects ([sk65420](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk65420)). 3. Close all SmartConsole windows (SmartConsole, SmartView Tracker, SmartView Monitor, etc.). 4. Connect with [GuiDBedit Tool](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk13009) to Security Management Server / Domain Management Server. 5. In the upper left pane, go to ***Table*** - ***Network Objects*** - ***network_objects*** . 6. In the upper right pane, select the relevant Security Gateway / Cluster object. 7. Press CTRL+F (or go to ***Search*** menu - ***Find*** ) - paste ***tunnel_keepalive_method*** - click on ***Find Next*** . 8. In the lower pane, right-click on the ***tunnel_keepalive_method*** - select ***Edit...*** - select the relevant Permanent Tunnel mode - click on ***OK***: |---------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Mode | Description | | *dpd* | Defines the *active DPD* mode. A peer receives DPD requests at regular intervals (10 seconds). This method has to be used for IKEv2 configuration. Note: This DPD monitoring configuration is the only one supported for VPN tunnel with X-Series chassis. | | *passive* | Defines the *passive DPD* mode. Other peers do not send DPD requests to this peer. Tunnels with passive peers are monitored according to existence of IPSec traffic and incoming DPD requests (in tunnel test, Check Point Security Gateway always sends keepalive packets). **Note** : to use this mode for some gateway, remote VPN peers should be enabled with the *forceSendDPDPayload* registry key as described in the "*DPD responder mode* " above (relevant only for Check Point remote VPN peers). Note: Check Point does not support this DPD monitoring configuration for VPN tunnel with X-Series chassis. Users must configure using the DPD monitoring "`dpd`". | | *tunnel_test* | (Default) Permanent Tunnel is monitored by tunnel test (as in former versions) works only between Check Point gateways. |

9. Save the changes: go to ***File*** menu - click on ***Save All*** . 10. Close the GuiDBedit Tool. 11. Connect with SmartConsole to Security Management Server / Domain Management Server. 12. Install the policy onto the relevant locally managed Security Gateway / Cluster object. | **Additional Configuration** There are several possibilities to define feature behavior under different conditions. |--------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Condition | Configuration Steps | | *IKE Initiation prevention* | By default, when a valid IKE SA is not available, a DPD request message will trigger a new IKE negotiation. To prevent this behavior, set the value of property ***dpd_allowed_to_init_ike*** to "*false*" in the Security Gateway: 1. Connect with SmartConsole to Security Management Server / Domain Management Server. 2. Go to ***File*** menu - click on ***Database Revision Control...*** - create a revision snapshot.. Note: Database Revision Control is not supported for VSX objects ([sk65420](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk65420)). 3. Close all SmartConsole windows (SmartConsole, SmartView Tracker, SmartView Monitor, etc.). 4. Connect with [GuiDBedit Tool](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk13009) to Security Management Server / Domain Management Server. 5. In the upper left pane, go to ***Table*** - ***Network Objects*** - ***network_objects*** . 6. In the upper right pane, select the relevant Security Gateway / Cluster object. 7. Press CTRL+F (or go to ***Search*** menu - ***Find*** ) - paste ***dpd_allowed_to_init_ike*** - click on ***Find Next*** . 8. In the lower pane, right-click on the ***dpd_allowed_to_init_ike*** - select ***Edit...*** - select "***false*** " - click on ***OK*** . 9. Save the changes: go to ***File*** menu - click on ***Save All*** . 10. Close the GuiDBedit Tool. 11. Connect with SmartConsole to Security Management Server / Domain Management Server. 12. Install the policy onto the relevant locally managed Security Gateway / Cluster object. | | *Delete IKE SAs for dead peer* | According to [RFC 3706](https://tools.ietf.org/html/rfc3706), a VPN gateway has to delete IKE SAs from a dead peer. This functionality is enabled, by default. To *disable* this feature, the ***DPD_DONT_DEL_SA*** environment variable has to be set to "0". * To check the current value of this environment variable: ***\[Expert@HostName\]# echo $DPD_DONT_DEL_SA*** * To set the desired value for this environment variable *permanently*: In order to set the value permanently, it has to be added manually to **all** Check Point shell scripts that define environment variables for the given operating system: * Show / Hide instructions for Security Gateway, which runs on Gaia / SecurePlatform / Linux / IPSO OS 1. In the ***$CPDIR/tmp/.CPprofile.sh*** script: Add this line: ***DPD_DONT_DEL_SA=0 ; export DPD_DONT_DEL_SA*** Under this line *INFODIR=/opt/CPinfo-10 ; export INFODIR* 2. In the ***$CPDIR/tmp/.CPprofile.csh*** script: Add this line: ***setenv DPD_DONT_DEL_SA 0*** Under this line: *setenv INFODIR "/opt/CPinfo-10"* 3. Restart all Check Point services: ***\[Expert@HostName\]# cpstop ; cpstart*** 4. Verify that the environment variable was applied: ***\[Expert@HostName\]# echo $DPD_DONT_DEL_SA*** Output should show "0" **Notes:** * To unset this environment variable permanently, remove it from the above shell scripts and restart Check Point services with "*cpstop;cpstart* " commands. * To unset this environment variable on-the-fly (in the current shell session): * In Bash shell (default shell for Expert mode): *\[Expert@HostName\]# unset DPD_DONT_DEL_SA \[Expert@HostName\]# echo $DPD_DONT_DEL_SA* * In Csh shell: *\[admin@HostName \~\]# unsetenv DPD_DONT_DEL_SA \[admin@HostName \~\]# echo $DPD_DONT_DEL_SA*

* Show / Hide instructions for Security Gateway, which runs on Windows OS 1. Start menu - Run... - ***"%WINDIR%\\system32\\rundll32.exe" sysdm.cpl,EditEnvironmentVariables*** - click on OK Alternatively: 1. Desktop - right-click on the "*My Computer* " icon - click on "*Properties*" 2. Windows Vista/7/2012: In the left pane, click on "*Advanced system settings*". 3. Go to "*Advanced*" tab. 4. At the bottom, click on "*Environment Variables...*" button.

2. Under "*System variables* " - click on "*New...*" * name: ***DPD_DONT_DEL_SA*** * value: ***0*** * and click "*OK* " to close the "*New System Variable*" window.

3. Click on "*OK* " to close the "*Environment Variables* " window. 4. Reboot the machine. 5. Verify that the environment variable was applied - run this command in Windows Command Prompt: ***C:\\\> set \| findstr DPD_DONT_DEL_SA*** Output should show "`DPD_DONT_DEL_SA=0`" **Notes:** * To unset this environment variable permanently, under "*System Variables* " click on this variable and click on "*Delete* " and reboot the machine. * To unset this environment variable on-the-fly (in the current shell session): Run this command in Windows Command Prompt: *C:\\\> set DPD_DONT_DEL_SA=*

| There are two ways to detect whether remote peer is "alive": 1. DPD response has been received from remote peer. 2. Incoming decrypted traffic has been received. In this case, no DPD request will be sent (this functionality is not supported when SecureXL is enabled and decrypted traffic is handled in it. When SecureXL is enabled, a DPD request will always be sent). Scenario 6 - 3rd party VPN peer proposes Phase 2 lifetime in kilobytes {#Scenario 6} ------------------------------------------------------------------------------------ ### Symptoms: * A Phase 2 lifetime in kilobytes is configured on the 3rd party VPN peer. Therefore, it offers it in addition to the lifetime in seconds. This means the peer wants to renegotiate the tunnel at the end of the lifetime in seconds, or after the number of specified kilobytes has been encrypted - whichever happens first. * On the Check Point Security Gateway, Phase 2 lifetime is configured only in seconds. Therefore, even though it accepts the proposal for Phase 2 lifetime from 3rd party VPN peer in kilobytes, it also sends back a "RESPONDER-LIFETIME" notification to notify that it is only going to enforce the Phase 2 lifetime in seconds. * With some 3rd party VPN vendors, it is necessary to match the exact initiator's proposal, including the lifetime in kilobytes. Otherwise, they will drop the tunnel and initiate a new negotiation over and over again. Show / Hide solution ### Solution: {#Toggle_Scenario_6} * Show / Hide the procedure for Simplified Mode In Simplified Mode, the configuration is per community and applis to VPN tunnels between peers of that community. Follow these steps: 1. Connect with SmartConsole to Security Management Server / Domain Management Server. 2. Go to ***File*** menu - click on ***Database Revision Control...*** - create a revision snapshot. Note: Database Revision Control is not supported for VSX objects ([sk65420](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk65420)). 3. Close all SmartConsole windows (SmartConsole, SmartView Tracker, SmartView Monitor, etc.). 4. Connect with [GuiDBedit Tool](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk13009) to Security Management Server / Domain Management Server. 5. In the upper left pane, go to ***Table*** - ***Managed Objects*** - ***communities*** . 6. In the upper right pane, select the relevant VPN community object. 7. Press CTRL+F (or go to ***Search*** menu - ***Find*** ) - paste ***ike_p2_use_rekey_kbytes*** - click on ***Find Next*** . 8. In the lower pane, right-click on the ***ike_p2_use_rekey_kbytes*** - select ***Edit...*** - select "***true*** " - click on ***OK*** . 9. In the upper right pane, select the relevant VPN community object. 10. Press CTRL+F (or go to ***Search*** menu - ***Find*** ) - paste ***ike_p2_rekey_kbytes*** - click on ***Find Next*** . 11. In the lower pane, right-click on the ***ike_p2_rekey_kbytes*** - select ***Edit...*** - delete the current value - enter the value of Phase 2 lifetime in kilobytes that is configured on the 3rd party VPN peer - click on ***OK*** . 12. Save the changes: go to ***File*** menu - click on ***Save All*** . 13. Close the GuiDBedit Tool. 14. Connect with SmartConsole to Security Management Server / Domain Management Server. 15. Install the policy onto the all the Security Gateway / Cluster objects in this community.

* Show / Hide the procedure for Traditional Mode In Traditional Mode, the configuration is per Security Gateway and applies to all tunnels, in which that Security Gateway participates. 1. In SmartConsole, open the Security Gateway / Cluster object. 2. Go to "*IPSec VPN* " tab - click on "*Traditional mode configuration...* " button - click on "*Advanced...* " button. 3. Check the box "*Renegotiate IPSec (IKE phase 2) Security associations every* " - enter the value of Phase 2 lifetime in kilobytes that is configured on the 3rd party VPN peer. 4. Click on OK. 5. Install policy on this Security Gateway / Cluster object. Scenario 7 - "Quick Mode Received Notification from Peer: invalid id information" error {#Scenario 7} ----------------------------------------------------------------------------------------------------- ### Symptoms: * "`Quick Mode Received Notification from Peer: invalid id information`" error when trying to establish a VPN tunnel with 3rd party device. Show / Hide solution ### Solution: {#Toggle_Scenario_7} Disable NAT inside for the relevant traffic in the VPN community by creating an explicit no-NAT rule for the relevant traffic - select "`= Original`" in the "Translated" columns of the NAT rule. *Example*: |---------------|---------------|---------|--------------|--------------|--------------|----------------|------------------------| | Original Packet ||| Translated Packet ||| Install On | Comment | | Source | Destination | Service | Source | Destination | Service | Install On | Comment | | Host_1 object | Host_2 object | `Any` | `= Original` | `= Original` | `= Original` | Policy Targets | Manual Static NAT rule |
Scenario 8 - Configuring Enhanced Link Selection for Redundant and Load-Sharing VPN Connections {#Scenario 8} ------------------------------------------------------------------------------------------------------------- ### Symptoms: When using multiple VPN connections across various external interfaces, administrators may face limitations in failover and load-sharing capabilities, especially when interoperating with third-party or cloud-based Site-to-Site IPsec VPNs. Traditional configurations may rely on Check Point's proprietary VPN Link Selection protocol, limiting compatibility with external vendors Show / Hide solution ### Solution: {#Toggle_Scenario_7} Enhanced Link Selection\ provides advanced interoperability by enabling multiple external interfaces for VPN connections, offering redundancy and load sharing without relying on proprietary protocols. This allows seamless integration with third-party and cloud-based Site-to-Site IPsec vendors. ### How Enhanced Link Selection Operates The Security Gateway monitors all active Site-to-Site VPN connections. Primary connections are prioritized, and failover automatically occurs if these become unavailable. Backup connections are selected based on a configured priority. ### Link Selection Granularity Traffic routes through distinct ISPs, with each active interface linking independently to its peer. Interfaces on the same gateway remain isolated, preventing cross-interface communication within the gateway. ### ISP Redundancy with Cloud Providers Enhanced Link Selection enables seamless redundancy, ensuring uninterrupted communication with third-party and cloud providers, even if a primary ISP connection fails. ### Configuration Steps for Enhanced Link Selection 1. **Create a VPN Community** * Define a Star or Meshed VPN Community to begin setup. 2. **Add Security Gateways** * Include required Security Gateways in appropriate sections (e.g., *Participating Gateways* for Meshed or *Center/Satellite Gateways* for Star VPNs). 3. **Configure Interfaces** * Select interfaces in the *Interfaces* section of the VPN Community. Override defaults as necessary for redundancy or load-sharing needs, including the option to specify Next Hop IPs and NAT settings if required. 4. **Define Redundancy Mode** * Set *Active* for load sharing or designate one interface as *Active* and others as *Backup* for high availability. Specify Backup priority levels to ensure continuity during ISP failures. 5. **Implement Dead Peer Detection (DPD)** * Configure DPD to monitor VPN status and enable link failover. 6. **Verify Failover** * Monitor with tools such as `fw monitor` or `tcpdump` to confirm failover functionality and active IKE sessions with backup IPs during transitions. ### Limitations * Unsupported configurations include Quantum Spark Gateways, DAIP Security Gateways, setups with multiple IPv6 addresses on a single interface, Large Scale VPN (LSV), Remote Access VPN, and ElasticXL. . --- # Agent Instructions This content is from the Check Point Support Center (https://support.checkpoint.com), the official knowledge base for Check Point cybersecurity products. ## Navigating This Knowledge Base - **Complete index**: [llms.txt](https://support.checkpoint.com/llms.txt) - **All SK articles**: [SecureKnowledge Sitemap](https://support.checkpoint.com/sitemaps/secureknowledge-sitemap-index.xml) - **SK article URL pattern**: `https://support.checkpoint.com/results/sk/{skId}` - **Markdown responses**: AI bot User-Agents automatically receive `text/markdown` content