Remote Access VPN throughput significantly lower than connection speed – R81.20 / E89.11

[Romaryo]

Hi everyone,

we are currently investigating a performance issue with Check Point Remote Access VPN and I would appreciate any ideas or experiences with similar behavior.

Our setup:

• Check Point Security Gateway: R81.20
• ClusterXL
• Remote Access VPN Client: E89.11 for Windows
• IPsec Remote Access VPN
• Client Internet connection: ~50 Mbps
• Download speed through the VPN: only ~20 Mbps

Without the VPN connection, the client can utilize approximately the full 50 Mbps. As soon as the Check Point VPN tunnel is established, the download throughput drops to around 20 Mbps.

We initially suspected an MTU/fragmentation issue. The Check Point virtual adapter already uses an MTU of 1350. As a test, I also changed the MTU of the physical Windows network adapter to 1360 and 1350, but this did not result in any noticeable improvement.

The Security Gateway itself does not appear to be under significant CPU load during the tests.

We are planning to perform additional tests with iperf3 against an internal server, including:

• single TCP stream
• multiple parallel TCP streams
• reverse direction
• UDP test

Before going deeper into debugging, I wanted to ask:

Has anyone experienced similar throughput limitations with E89.x Remote Access VPN clients on R81.20?

In particular, are there any known issues or recommended settings regarding:

• Remote Access IPsec performance
• SecureXL / VPN acceleration
• CoreXL
• NAT-T
• TCP MSS / PMTU
• Endpoint VPN client processing
• differences between single and multiple TCP streams

Are there any specific commands, counters, SKs, or debug procedures you would recommend to determine whether the bottleneck is on the Endpoint client or the Security Gateway?

best regards,

Roman

[simonemantovani]

Hello

first you could take a look at this post: https://community.checkpoint.com/t5/AI-Network-Firewall/VPN-performance-limits/td-p/141700  and refer, for example, to the mentioned SKs.

You could try to change the encryption algorithm used for VPN (if you not already change these parameters).

About the performance issue, when it started? the vpn was it always slow? Are you using the latest JHF?

[Chris_Atkinson]

Are you using algorithms that are AES-NI friendly?

Things like Vistor mode might be a factor but also has 3DES been disabled?

https://support.checkpoint.com/results/sk/sk177966

[Romaryo]

HW 16200 

ESP: AES-256 + SHA256

[Timothy_Hall]

1) Make sure you do not have Extended Logging set on the VPN client: sk177125: Traffic bandwidth/download speed is very low when Endpoint Clients are connected to VPN

2) Bring up the SmartView Monitor while VPN clients are connected, and be absolutely sure they are not using 3DES/MD5 for IPSec Phase 2, as that was the default for a very long time; also check the state of Visitor Mode and NAT-T under the Users...All Users view.

3) If Visitor Mode is not active for your user, you can try forcing it to rule out MTU issues or possible shaping/limiting of ESP but not port 443: sk107433: How to change transport method with Endpoint Clients

4) In R81.20 you still have the ability to disable SecureXL for all VPN traffic with vpn accel off, might be worth a try to see if anything changes performance-wise.

5) The 2x Intel Xeon Silver CPUs in the 16200 have plenty of juice and support AES-NI (may want to confirm it has been properly detected with fw ctl get int AESNI_is_supported), I doubt it is some kind of single-core performance limitation.

[Romaryo]

@Timothy_Hall Thank you very much!

At first glance, I think we have found the solution, and it appears to be described in SK177125.

I will ask our team to verify this on other users’ laptops as well. On my laptop, I was able to reproduce both the issue and the solution successfully.

I will keep you updated on our further progress.

Is there any way to change this parameter centrally? We are using the Standalone version. For example, would it be possible to configure it via a TTM file on the gateway?