> Source: [sk105119](https://support.checkpoint.com/results/sk/sk105119) # sk105119 - Best Practices - VPN Performance | Property | Value | |----------|-------| | Solution ID | sk105119 | | Date Created | 2015-05-04 | | Last Modified | 2026-09-03 | | Technical Level | General | | Products | Security Gateway | | Versions | R82.10, R82, R81.20, R81.10 (EOS), R81 (EOS) | | OS | Gaia | ## Solution This article provides general performance guidelines for working with VPN in Security Gateway **Table of Contents:** 1. Interfaces Affinity 2. VPN and SecureXL 3. Choosing an encryption algorithm and AES-NI 4. Insights into SSL VPN Gateway Performance 5. Related documentation ### Interface Affinity {#Interface Affinity} * Interface Affinity Configuring interfaces affinity manually is usually not needed. As an example, we will use a 12600 appliance with a default CoreXL configuration of "2:10": * 2 CPU cores are used for Secure Network Distributor (SND), and * 10 CPU cores are used for CoreXL Firewall instances, and * 2 NICs - 1 LAN, 1 WAN. * Enabling Multi-Queue is recommended when a single interface receives too much traffic for a single CoreXL SND to handle (refer to "Related documentation" section). If the CPU utilization on the CPU cores running as CoreXL SND instances is high, while the CPU utilization on CPU cores running as CoreXL Firewall instances is relatively idle, then administrator should consider reducing the number of CoreXL Firewall instances from 10 to 8, to release more CPU cores to run as CoreXL SND instances. This is relevant only if you have 2 NICs with Multi-Queue enabled, or 4 NICs. ### VPN and SecureXL (relevant to Site-to-Site and IPSec Remote Access) {#VPN and SecureXL} When SecureXL is enabled, Encrypt-Decrypt actions usually take place on SecureXL level (on CPU cores running as CoreXL SND instances). All VPN traffic will be handled on the CPU cores running as CoreXL SND instances under the following conditions: * Only "Firewall" and "IPSec VPN" Software Blades are enabled * There are no fragmented packets * SecureXL acceleration is not disabled by any of the security rules (see [sk32578](https://support.checkpoint.com/results/sk/sk32578)) * VPN features that are disqualified from SecureXL (see below) are disabled If all the above conditions are met, all VPN traffic will be handled on CPU cores running as CoreXL SND with minimum traffic being forwarded to the CoreXL Firewall instances, resulting in multi-core processing of VPN traffic (depending on the number of CPU cores running as CoreXL SND). The following VPN features are handled by CPU cores running as CoreXL Firewall instances: * Any compression algorithms (go to IPSec VPN Community properties - "Advanced Settings" page - "Advanced VPN Properties") * Any transport mode SA (used in L2TP clients and GRE tunnels) * Multicast IPsec (GDOI) * "Monitoring" Software Blade - if in addition to "System Counters", also "Traffic" counters are enabled in the Security Gateway object (in such a case, connections are flagged with the "Accounting" flag in the output of the "`fwaccel conns`" command) * Any Software Blades other than "Firewall" are enabled ### AES-NI {#Choosing an encryption algorithm and AES-NI} [AES-NI](https://software.intel.com/en-us/articles/intel-advanced-encryption-standard-instructions-aes-ni) is Intel's dedicated instruction set, which significantly improves the speed of Encrypt-Decrypt actions and allows one to increase VPN throughput (Site-to-Site, Remote Access and Mobile Access). The general speed of the system depends on additional parameters. **Check Point supports AES-NI on these appliance models:** Notes: * **All Appliance Models released in the year 2024 and later, support AES-NI.** * Gaia OS must run with the 64-bit kernel (this is the default in R80.40 and higher). * For the End of Support dates for appliance models, see [Support Life Cycle Policy](http://www.checkpoint.com/support-services/support-life-cycle-policy/). Enter the string to filter this table: |-----------------------------------------------------------|----------------------------------------------------------------|---------------| | Appliance Model | Home Page SK | Starting From | | Quantum Force 29000 | [sk180520](https://support.checkpoint.com/results/sk/sk180520) | R81.20 | | 28000, 28600 | [sk152733](https://support.checkpoint.com/results/sk/sk152733) | R80.40 | | 26000 | [sk152733](https://support.checkpoint.com/results/sk/sk152733) | R80.40 | | 23500, 23800, 23900 | [sk107516](https://support.checkpoint.com/results/sk/sk107516) | R77.30 | | 21400, 21600, 21700, 21800 | [sk68701](https://support.checkpoint.com/results/sk/sk68701) | R76 | | Quantum Force 19000 | [sk180520](https://support.checkpoint.com/results/sk/sk180520) | R81.20 | | 16000, 16200, 16600HS | [sk152733](https://support.checkpoint.com/results/sk/sk152733) | R80.40 | | 15400, 15600 | [sk107516](https://support.checkpoint.com/results/sk/sk107516) | R77.30 | | 13500, 13800 | [sk93470](https://support.checkpoint.com/results/sk/sk93470) | R77.30 | | 12400, 12600 | [sk68700](https://support.checkpoint.com/results/sk/sk68700) | R77.30 | | Quantum Force 9000 | [sk181698](https://support.checkpoint.com/results/sk/sk181698) | R81.20 | | 7000 | [sk139932](https://support.checkpoint.com/results/sk/sk139932) | R80.40 | | 6400, 6700 | [sk139932](https://support.checkpoint.com/results/sk/sk139932) | R80.40 | | 6200, 6500, 6600, 6800, 6900 | [sk139932](https://support.checkpoint.com/results/sk/sk139932) | R80.30 | | 5600, 5800, 5900 | [sk110053](https://support.checkpoint.com/results/sk/sk110053) | R77.30 | | 3800 | [sk110052](https://support.checkpoint.com/results/sk/sk110052) | R80.40 | | 3600 | [sk110052](https://support.checkpoint.com/results/sk/sk110052) | R80.30 | | 3100, 3200 | [sk110052](https://support.checkpoint.com/results/sk/sk110052) | R77.30 | | LightSpeed QLS250, QLS450, QLS650, QLS800, MLS200, MLS400 | [sk176466](https://support.checkpoint.com/results/sk/sk176466) | R81.10 | | Scalable Chassis 44000 / 64000 | [sk65305](https://support.checkpoint.com/results/sk/sk65305) | R76SP.50 | | Scalable Chassis 41000 / 61000 | [sk65305](https://support.checkpoint.com/results/sk/sk65305) | R76SP | {#Unique_ID1Table} On these appliances, AES-NI is *enabled* by default. AES-NI is also supported on Open Servers. Make sure that Gaia OS runs in the 64-bit mode. **Note:** Refer to [sk110549 - vSEC Virtual Edition (VE) Gateway support for AES-NI on VMware ESX](https://support.checkpoint.com/results/sk/sk110549). Affected encryption algorithms include: * AES-CBC (128-bit and 256-bit) * AES-GCM (128-bit and 256-bit), which shows the most significant improvement - with AES-NI, it is faster than AES-CBC, when both sides support AES-NI. Without AES-NI support, it is slightly slower than AES-CBC + HMAC-SHA1. AES-GCM is **not** recommended in these scenarios: * Check Point Appliances, which do not support AES-NI - 12200 model, all 4000 series, all 2000 series (in addition, Gaia OS in the 32-bit mode does not support AES-NI). * VPN Communities that contain Check Point SMB 600 / SMB 1100 / SMB Security Gateway 80 Appliances - best throughput can be achieved with AES-128. (This limitation was resolved in Spark Firewall models 1500 and newer.) AES-GCM is **not** supported by the SAM card in 21000 appliances ([sk68701](https://support.checkpoint.com/results/sk/sk68701)) - best throughput can be achieved with AES-128. #### Visitor Mode * Visitor Mode is supported by the legacy SecureClient and by Endpoint Security Client / Endpoint Connect Client. Each packet in Visitor Mode is processed in user space, which causes a load on CPU on the Security Gateway (only several hundred Visitor Mode clients can be handled by the Security Gateway). In SecureClient, if enabled by the user, Visitor Mode is never automatically turned off. It is recommended that users enable Visitor Mode only when essential (typical to Airport and Hotel Wi-Fi spots), and disable it afterwards. Large-Scale support for Visitor Mode is included in: * R81 and higher * [R80.40 Jumbo Hotfix Accumulator](https://sc1.checkpoint.com/documents/Jumbo_HFA/R80.40/Default.htm), Take 53 and higher (see PRJ-12102) ### Insights into SSL VPN Gateway Performance {#Insights into SSL VPN Gateway Performance} * #### Hardware * It is recommended to use a dedicated Check Point appliance as the SSL VPN Gateway. * A Load Sharing cluster is preferable to a stronger appliance in most cases. * In the Load Sharing mode, Sticky Decision Function (SDF) is enabled automatically. By design, SDF disables SecureXL, which decreases the overall performance and the performance of IPsec clients. You may disable Sticky Decision Function (SDF) in the cluster object in SmartConsole. When Mobile Access Software Blade is enabled, Sticky Decision Function (SDF) is forced and cannot be disabled. * #### General * Simultaneous Logins - lowering the number of simultaneous logins increases capacity. * Web compression - saves bandwidth, but increases load on Security Gateway's CPU. * Logging in security rules - increases the load on the Security Gateway's CPU. * #### Sizing * The appliance sizing tool ([sk88160](https://support.checkpoint.com/results/sk/sk88160)) should only be used for 5000 users or less. * It is important to understand the web application complexity when using sizing tools. Tunneled applications, such as Remote Desktop users, consume considerably more bandwidth than Outlook Web Access (OWA). In turn, OWA consumes more bandwidth than simple web applications. * #### Security * IPS - disabling some Web Intelligence protections may decrease CPU utilization on the Security Gateway. * Traditional Anti-Virus causes throughput and concurrent connections degradations in SSL VPN. * Client Authentication - using client certificate for authentication increases CPU utilization the most. * #### Network Configuration * To improve latency, verify short response time of internal servers, DNS servers, and Proxy server. * #### SSL Termination * Starting from R76, increasing the number of CoreXL Firewall instances linearly increases the SSL session rate. * #### Web Applications * Apache Keep-Alive HTTP requests are served by Apache Web Server processes. Due to the fact that these processes are *not* multi-threaded, each Apache process serves *one* HTTP request at a time. Each Apache process consumes approximately 2 Megabytes of RAM per HTTP request. In order not to exhaust the machine's RAM, there is a cap of \~15% of machine's RAM for Apache processes. For example, a machine with 2GB RAM will have up to 148 Apache processes. The 15% cap is for Mobile Access Software Blade. It is possible to configure Mobile Access as a single Software Blade running on a dedicated Security Gateway (refer to [sk53003](https://support.checkpoint.com/results/sk/sk53003)). However, in R75.30 and lower, the total number of Apache processes could not exceed 990 - even if there was enough RAM. Usually, an Apache process can serve up to 4 users. Therefore, if *\[number of users\] \< \[4 x number of Apache process\]*, then consider reducing the cap to free memory for other uses. When an HTTP request is served, the connection may not be immediately closed. Apache has the possibility to keep the connection open for a configurable period of time though keep-alives. The keep-alive configuration is used to reduce web browser request latency by allowing subsequent requests on the same connection to be served by this Apache process instead of spawning a new instance. Due to the fact that there is a cap for the number of Apache processes, this configuration could cause HTTP requests to be dropped because Apache processes are "waiting" for requests before handling other connections. By default the keep-alive is sent every 2 seconds. * For maximum capacity, *disable* Apache keep-alive. * For minimum latency, *increase* the Apache keep-alive * Avoid SSL on internal traffic * Prefer Kerberos over NTLM for authentication, because NTLM authentication is re-done for every TCP connection. Using Kerberos reduces bandwidth between the Security Gateway and the internal server, and reduces latency for end users. * Hostname Translation is preferred over Link Translation because Hostname Translation configuration reduces CPU and RAM utilization, improves throughput and latency, and reduces bandwidth. * Link Translation Domain - remove external websites from the list of websites that will be translated for improved performance and capacity. * More than 700 concurrent ActiveSync clients are supported. * #### SNX Application Mode * There can be up to 512 simultaneous SNX Application Mode connections (limit of file descriptors in the operating system). * Throughput is limited by one CPU core for SSL processing. ### Related Documentation {#Related documentation} * [sk104760 - ATRG: VPN Core](https://support.checkpoint.com/results/sk/sk104760) * [sk98737 - ATRG: CoreXL](https://support.checkpoint.com/results/sk/sk98737) * [sk98722 - ATRG: SecureXL for R80.20 and higher](https://support.checkpoint.com/results/sk/sk153832) * [sk93000 - SMT (HyperThreading) Feature Guide](https://support.checkpoint.com/results/sk/sk93000) * [sk118097 - MultiCore Support for IPsec VPN](https://support.checkpoint.com/results/sk/sk118097) * Also see the [ClusterXL Administration Guide](https://support.checkpoint.com/product/531#f-commonsource=C.%20Documentation) for the relevant version. --- # 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