Support Center > Search Results > SecureKnowledge Details
New VPN features in R77.20 and later
Solution

 Table of Contents

  1. MultiCore Support for SSL
  2. MSS adjustments for Clear and IPsec traffic
  3. Setting the value of VPN kernel parameters
  4. Third party connectivity improvements
  5. DHCP Option 119 support for Remote Access clients (RFC 3397)
  6. 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:

Property
Name
Property
Description
Configuration
Method
Configuration
Scope
Valid
Values
fw_clamp_tcp_mss

Controls MSS Adjustment (Clamping) for FireWall level traffic on all managed Security Gateways.

Refer to sk61221.

Exists in versions lower than R77.20.

1) On Security Gateway - Kernel parameter

2) On Management Server - GuiDBEdit Tool

1) On Security Gateway - Per Gateway

2) On Management Server - Global

1) On Security Gateway:

  • 1 - enabled
  • 0 - (default) disabled

2) On Management Server:

  • true - enabled
  • false - (default) disabled
fw_clamp_tcp_mss_control Controls MSS Adjustment (Clamping) on specific Security Gateway.

New in R77.20. Requires R77.20 Management.
GuiDBedit Tool

Per Gateway

Note: On VSX Gateway, this attribute must be set for both Virtual System and for VSX Gateway itself

  • true - enabled
  • false - (default) disabled
mss_value Controls MSS value for MSS Adjustment (Clamping) on specific interface on specific Security Gateway.

New in R77.20. Requires R77.20 Management.
GuiDBedit Tool

Per interface

Note: On VSX Gateway, this attribute must be set for both Virtual System and for VSX Gateway itself

  • -1 - disable MSS clamping
  • 0 - (default) enable MSS clamping - MSS value is derived from interface's MTU
  • positive integer - MSS clamping enabled and this value is used
fw_clamp_vpn_mss

Controls MSS Adjustment (Clamping) for IPsec VPN blade traffic independent of TCP clamping described above.
Must also enable the sim_clamp_vpn_mss.

New in R77.20.

Refer to sk112094.

Kernel parameter Per Gateway
  • 1 - enabled
  • 0 - (default) disabled

Can be enabled on Security Gateway:

  • Either on-the-fly (does not survive reboot):

    # fw ctl set int fw_clamp_vpn_mss 1

  • Or permanently per sk26202:

    Add this line to $FWDIR/boot/modules/fwkern.conf file and reboot:
    fw_clamp_vpn_mss=1
sim_clamp_vpn_mss

Controls MSS clamping in SecureXL (SecureXL VPN) only for IPsec VPN blade traffic independent of TCP clamping described above.
Must also enable the fw_clamp_vpn_mss.

New in R77.20.

Refer to sk112094.

Kernel parameter Per Gateway
  • 1 - enabled
  • 0 - (default) disabled

Can be enabled on Security Gateway with enabled SecureXL only permanently:

Add this line to $PPKDIR/boot/modules/simkern.conf file and reboot:
sim_clamp_vpn_mss=1

Important: In Gaia Embedded, the location of simkern.conf is $FWDIR/modules/simkern.conf. $PPKDIR does not exist.

Important Notes:

  • 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
    Example:
    [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
    Example:
    [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:

    1. Create the $FWDIR/boot/modules/vpnkern.conf file (if it does not already exit):

      [Expert@HostName]# touch $FWDIR/boot/modules/vpnkern.conf

    2. Edit the $FWDIR/boot/modules/vpnkern.conf file in Vi editor:

      [Expert@HostName]# vi $FWDIR/boot/modules/vpnkern.conf

    3. Add the following line (spaces are not allowed):

      PARAMETER=VALUE

      Example:
      ipsec_mtu_icmp_wait_timeout=4
    4. Save the changes and exit from Vi editor.

    5. Check the contents of the $FWDIR/boot/modules/vpnkern.conf file:

      [Expert@HostName]# cat $FWDIR/boot/modules/vpnkern.conf

    6. Reboot the Security Gateway.

 

(4) Third party connectivity improvements

 

(4-A) Introduction

  • 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

  • ike_use_largest_possible_subnets - true (default):

    • Smaller subnets adjoined to larger sub-nets (e.g., 10.0.0.0/25 and 10.0.0.128/25 adjoined to 10.0.0.0/24). This behavior is called "supernetting". Done for all VPN peers (Check Point Gateways and 3rd party VPN devices).
    • Run the "vpn tu" command - select "List all IPsec SAs". We will see only one IPsec SA for traffic from 10.0.0.20(/25) and from 10.0.0.130(/25).
    • No connectivity to 3rd party VPN devices that are configured with original (smaller) sub-nets.
  • ike_use_largest_possible_subnets - false:

    • No "supernetting" for all devices.
    • For externally managed Check Point Gateways, IPsec entry (IPsec SA) per host.
    • Externally managed Check Point Gateways: Run the "vpn tu" command - select "List all IPsec SAs". We will see two SAs, for traffic from 10.0.0.20(/25) and from 10.0.0.130(/25).
    • Connectivity to 3rd party VPN devices available.

 

(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.
  Security Gateway R77.20 and above Security Gateway R77.10 and lower
Check Point Management R77.20 and above
  • ike_use_largest_possible_subnets - true (default) + ike_enable_supernet - true (default for upgrade):

    See "Behavior in R77.10 and lower" for the case, in which ike_use_largest_possible_subnets - true (default).

  • ike_use_largest_possible_subnets - false + ike_enable_supernet - true:

    See "Behavior in R77.10 and lower" for the case, in which ike_use_largest_possible_subnets - false.

  • ike_use_largest_possible_subnets - true/false + ike_enable_supernet - false (default on new installations):

    • "supernetting" is disabled ONLY for 3rd party VPN devices (according to "third_party_devices" table).
    • IPsec entry per "smaller" sub-net for 3rd party VPN devices.
    • IPsec entry per adjoined ("bigger") sub-net for all Check Point devices (including externally managed).
  • ike_use_largest_possible_subnets - true + "ike_enable_supernet" - true / false:

    See "Behavior in R77.10 and lower" for the case, in which ike_use_largest_possible_subnets - true (default).

  • "ike_use_largest_possible_subnets" - true + ike_enable_supernet - true / false:

    See "Behavior in R77.10 and lower" for the case, in which ike_use_largest_possible_subnets - false.

Check Point Management R77.10 and lower
  • ike_use_largest_possible_subnets - true + ike_enable_supernet - true / false:

    See "Behavior in R77.10 and lower" for the case, in which ike_use_largest_possible_subnets - true (default).

  • ike_use_largest_possible_subnets - false + ike_enable_supernet - true / false:

    See "Behavior in R77.10 and lower" for the case, in which ike_use_largest_possible_subnets - false.

See Behavior in R77.10 and lower section.

 

(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.

Instructions:

  1. Connect with SmartDashboard 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).

  3. Close all SmartConsole windows (SmartDashboard, SmartView Tracker, SmartView Monitor, etc.).

  4. Connect with GuiDBedit Tool to Security Management Server / Domain Management Server.

  5. In the upper left pane, go to 'Table' - 'Global Properties' - 'properties'.

  6. In the upper right pane, select 'firewall_properties.

  7. Press CTRL+F (or go to 'Search' menu - 'Find') - paste ike_enable_supernet - click on 'Find Next'.

  8. In the lower pane, right-click on the 'ike_enable_supernet' - 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 SmartDashboard to Security Management Server / Domain Management Server.

  12. Install the policy on all managed Security Gateway / Cluster objects.

 

(4-F) Known limitations

If the following conditions apply:

  1. Value of "ike_use_largest_possible_subnets" parameter is set to false
  2. Value of "ike_enable_supernet" parameter is set to true (if available)
  3. 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

(6-A) Introduction

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:

Behavior Explanation Kernel parameters and their values
Always Fragment Do not send ICMP messages
  • sim_ipsec_dont_fragment=0
  • sim_keep_DF_flag=0
"Old behavior" in R77.10 and lower Send ICMP messages endlessly and drop the packet
  • sim_ipsec_dont_fragment=0
  • sim_keep_DF_flag=1
"New behavior" in R77.20 and above Send ICMP messages for 2 seconds and then fragment the packet
  • sim_ipsec_dont_fragment=1
  • value of sim_keep_DF flag does not matter

 

(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.

Related solutions:

Applies To:
  • 01446679 , 01562144 , 01504559 , 01554558 , 01521578 , 01448860 , 01505962
  • 01820334 , 01821023 , 02364974 , 01958358 , 01822697

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