Table of Contents
MultiCore Support for SSL
MSS adjustments for Clear and IPsec traffic
Setting the value of VPN kernel parameters
Third party connectivity improvements
DHCP Option 119 support for Remote Access clients (RFC 3397)
General improvements in VPN stability
This article describes the VPN features that were integrated into R77.20 and above.
(1) MultiCore Support for SSL
The SSL MultiCore feature is based on Check Point CoreXL technology, which enhances Security Gateway performance by enabling the CPU processing cores to concurrently perform multiple tasks.
When the SSL MultiCore feature is used, SSL traffic is distributed among all available CoreXL FW instances, hence, fully utilizing MultiCore capabilities allowing to significantly increase SSL throughput for Multi Portals, Mobile Access Portal, SNX tunnels, VPN Mobile, etc.
For more information, refer to sk101223 - MultiCore Support for SSL in R77.20 and above.
(2) MSS adjustments for Clear and IPsec traffic
During TCP handshake, both client and server send MSS values in SYN and SYN/ACK packets to notify the other side the Maximum Segment Size (MSS) they are willing to accept. To prevent packet fragmentation, MSS values can't be larger than the MTU values along the communication path. Several variables are used to control TCP MSS clamping and VPN traffic clamping and their configuration is listed below:
- All features that are enabled for clear traffic also affect the IPsec VPN traffic.
- fw_clamp_vpn_mss and sim_clamp_vpn_mss should be enabled together. Otherwise, if SecureXL is enabled, only one traffic direction will be clamped. In addition, VPN MSS clamping will change only encrypted outgoing TCP traffic. If incoming encrypted traffic should be changed as well, it should be changed on the remote VPN peer.
In addition, a hotfix is required from sk112094 - MSS value is not applied to IPsec VPN traffic, although MSS Adjustment (Clamping) for IPsec VPN traffic is enabled.
- In cluster, the MSS value (mss_value) has to be set in the object of each cluster member, as well as in the cluster object itself.
- In VSX gateway / VSX cluster, the MSS value (mss_value) has to be set in the object of each Virtual System.
- While working with traffic that undergoes CPAS (e.g., when Proxy mode is enabled, or HTTPS Inspection is enabled), then the connection will be broken by CPAS into two parts (between Client and the Security Gateway; and between Security Gateway and the Server). In that state, if MSS is enabled only on one interface of Security Gateway, then only one part of the connection will obey the new MSS value. To make sure the MSS value will continue to the next interface of Security Gateway, make sure to enable it on both interfaces involved in the connection.
- IPSO OS:
- In IPSO OS lower than v6.2, changing the value of fw_clamp_tcp_mss parameter must be done in $FWDIR/boot/modules/fwkern.conf file and not via GuiDBedit Tool.
- The MSS feature is not supported in IPSO 6.2 and above with enabled SecureXL.
- The above applies to Centrally managed SMB devices such as 1100/1400 as well, however, the firmware from sk114675 needs to be installed to avoid the mentioned issue there involving clamping and WebUI/SSH access.
- In R80.10 Management server, the GuiDBedit has to be *closed* after making changes to MSS values (or any value for that matter) *before* pushing the policy. Otherwise the changes will not be "published". Clicking on "save changes" without closing the program is not going to work.
(3) Setting the value of VPN kernel parameters
To check the current value of a kernel parameter:
[Expert@HostName]# fw ctl get int PARAMETER
[Expert@HostName]# fw ctl get int ipsec_mtu_icmp_wait_timeout
To set the desired value for a kernel parameter on-the-fly (does not survive reboot):
[Expert@HostName]# fw ctl set int PARAMETER VALUE
[Expert@HostName]# fw ctl set int ipsec_mtu_icmp_wait_timeout 4
To set the desired value for a kernel parameter permanently:
Follow sk26202 (Changing the kernel global parameters for Check Point Security Gateway).
For Gaia / SecurePlatform OS:
$FWDIR/boot/modules/vpnkern.conf file (if it does not already exit):
[Expert@HostName]# touch $FWDIR/boot/modules/vpnkern.conf
$FWDIR/boot/modules/vpnkern.conf file in Vi editor:
[Expert@HostName]# vi $FWDIR/boot/modules/vpnkern.conf
Add the following line (spaces are not allowed):
- Save the changes and exit from Vi editor.
Check the contents of the
[Expert@HostName]# cat $FWDIR/boot/modules/vpnkern.conf
- Reboot the Security Gateway.
(4) Third party connectivity improvements
- The "supernetting" feature enables to adjoin smaller sub-nets to a bigger one ("supernets"). This feature makes it possible to decrease the number of IPsec SAs that are created per sub-net. This feature has a problem of connectivity with third party devices. Those devices don't support "supernetting", and as a result a "no valid SA" error can occur. An optional solution for this problem can be found in sk108600 (Scenario 1), but in this solution the supernetting is disabled for all devices.
- The improvement comes to make possible disabling "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.
- New behavior is available in R77.20 and above.
(4-B) Behavior from R80.20
Important: From 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.
Before R80.20, 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".
(4-C) Behavior in R77.10 and lower
(4-D) New behavior in R77.20 and above
Prerequisite: IPsec VPN Community configured with "One VPN tunnel per subnet pair".
The table below is set up as follows:
- First row deals with the cases, in which Check Point Management is R77.20 and above. The adjacent cell in the middle column deals with the case where the Security Gateway is R77.20 and above. The cell in the 3rd column deals with the case where the Security Gateway is R77.10 and lower. In each cell, behavior resulting from various permutations of the parameter values are examined.
- Second row deals with the cases, in which Check Point Management is R77.10 and lower. The adjacent cell in the middle column deals with the case where the Security Gateway is R77.20 and above. The cell in the 3rd column deals with the case where the Security Gateway is R77.10 and lower. In each cell, behavior resulting from various permutations of the parameter values are examined.
(4-E) How to enable the new behavior in R77.20 and above
Using GuiDBedit Tool, set the value of "ike_enable_supernet" parameter to false.
Note: The default value of "ike_enable_supernet" parameter is true for upgrades, and false on new installations.
- Connect with SmartDashboard to Security Management Server / Domain Management Server.
- Go to '
File' menu - click on '
Database Revision Control...' - create a revision snapshot.
Note: Database Revision Control is not supported for VSX objects (sk65420).
- Close all SmartConsole windows (SmartDashboard, SmartView Tracker, SmartView Monitor, etc.).
- Connect with GuiDBedit Tool to Security Management Server / Domain Management Server.
- In the upper left pane, go to '
Table' - '
Global Properties' - '
- In the upper right pane, select '
- Press CTRL+F (or go to '
Search' menu - '
Find') - paste
ike_enable_supernet - click on '
- In the lower pane, right-click on the '
ike_enable_supernet' - select '
Edit...' - select "
false" - click on '
- Save the changes: go to '
File' menu - click on '
- Close the GuiDBedit Tool.
- Connect with SmartDashboard to Security Management Server / Domain Management Server.
- Install the policy on all managed Security Gateway / Cluster objects.
(4-F) Known limitations
If the following conditions apply:
- Value of "ike_use_largest_possible_subnets" parameter is set to false
- Value of "ike_enable_supernet" parameter is set to true (if available)
- There is an externally managed Check Point Gateway and 3rd party VPN device with the same sub-net in the encryption domain (even if they are in different communities)
Then traffic to the externally managed Check Point Gateway will be handled as traffic to 3rd party VPN device. This means IPsec SA per sub-net (without "supernetting").
(5) DHCP Option 119 support for Remote Access clients (RFC 3397)
Support for the DHCP Option 119 (DNS Domain Search Option, RFC 3397) for Remote Access Office Mode was added in R77.20.
For more information, refer to sk98353 - Check Point support for DHCP option 119 (Domain Search Option) per RFC 3397.
(6) General improvements in VPN stability
Refer to R77.20 Resolved Issues.
SecureXL fragmentation enhancement - added by a hotfix to R77.20
Prior to R77.20, if clear text packet, after encryption, requires fragmentation and the clear packet has the DF (Don't Fragment) bit set, then SecureXL would keep sending ICMP packets to reduce the packet length and drop the original packet.
If the sender obeys the ICMP messages and reduces the packet length, then everything works fine. However, if sender does not obey the ICMP message, or if these ICMP messages are dropped along the way, then connectivity would be affected.
This functionality can be changed by one of the following:
- Disabling of the kernel parameter sim_keep_DF_flag, which will cause fragmentation for all VPN traffic that exceeds the MTU value
- Disabling of SecureXL
For more information about VPN fragmentation, refer to sk98074 - MTU and Fragmentation Issues in IPsec VPN.
This hotfix, adds the new kernel parameter sim_ipsec_dont_fragment. If this parameter is enabled, then the behavior of Security Gateway with enabled SecureXL changes to the following:
- If the clear text packet requires fragmentation after encryption, then the Security Gateway would start sending an ICMP notification to the sender to reduce packet length. It puts the entry with Source IP address and Destination IP address in a table to "remember" this packet.
- If the length of the packet does not change during 2 seconds, then Security Gateway will "give up" and start fragmenting the encrypted packets even if the DF (Don't Fragment) bit is set in the packet.
This behavior mirrors the behavior of FireWall in this case.
Note that this parameter sim_ipsec_dont_fragment is independent of the parameter sim_keep_DF_flag, and there are 3 possible configurations:
(6-B) How to get the new behavior
If you wish to use this new feature, then contact Check Point Support to get a required 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.
(6-C) How to enable kernel parameter
In order to enable sim_ipsec_dont_fragment kernel parameter, refer to the procedure provided in sk98070 - Traffic sent over VPN tunnel does not reach its destination because SecureXL does not start fragmenting the packets.
- 01446679 , 01562144 , 01504559 , 01554558 , 01521578 , 01448860 , 01505962
- 01820334 , 01821023 , 02364974 , 01958358 , 01822697