VPN - connection speed reduces by 50%

[Kraucer_Mazuco]

When I connect VPN, my connection speed reduces by 50%. I know several people with the same problem. Has anyone else noticed this? I have two servers in my company, they are on the same network. One is accessible via the Internet. In them I hosted a test file with a size of 200 MB. When I download via Internet the rate is 4.2 MB/s; when I go down via VPN the rate goes to 2.2 MB/s.

Details: S.O.: Windows 10
Client Version: E80.70 build 986001031

[PhoneBoy]

A few things:

1. Why are you posting your message text as "preformatted" in this case? It makes your post hard to read since the text must be scrolled. There is no need to format this particular text.

2. When your say your connection speed drops by 50%, how are you measuring this and to what sites? Are they sites reachable via the VPN or? Because, yes, VPNs have overhead to them and, if you're measuring throughput to a given site when connecting to a VPN versus not, it's going to be slower due to the encryption and packet overhead. Will it be 50% slower? Depends on the circumstances.

3. We also need some very basic details such as OS version, client version, and what gateway you are connecting to.

[Kraucer_Mazuco]

Thanks for the feedback, I've edited my question.

[PhoneBoy]

Any file transfer over a VPN is going to be slower than when you don't use a VPN.

This is because:

• Encryption and decryption takes additional CPU overhead on both endpoints.
• The original, unencrypted traffic is encapsulated in new packets, which means to transfer the same amount of effective data, more bits must be transmitted across the wire.
  
  • VPN encapsulation can also have impacts on the underlying application used to transfer the file due to the changes in packet sizes, causing additional packets to be necessary.

Is it going to be 50% slower?

It depends on a lot of factors, but it doesn't seem out of the question, especially given the transfer speeds you're talking about. 

[Kraucer_Mazuco]

Thank you for your consideration. The fact is that I have friends who use the same solution, including the same Internet service provider, without slowing down. Intriguing, is not it? Can you do a similar test?

[PhoneBoy]

Your friends could easily be seeing better results because:

• They have a different PC with different software loaded on it
• They are using a different modem and router
• The same ISP in their location performs better than it does yours

And that doesn't even begin to factor in what might be happening on the server end.

Without understanding the complete end-to-end picture, it's hard to say what is causing the difference in performance.

Further, without a complete understanding of those details, any test I might do would be unlikely to produce a meaningful result.

It's possible the TAC may be able to help you troubleshoot what's going on.

[Kraucer_Mazuco]

We use the same notebook model provided by the company, without access to changes in the software. We use the same broadband provider, same router model, we are in the same city.

TAC? I did not understand.

[PhoneBoy]

Even the same ISP in different physical locations within the same city can have different performance characteristics.

Wired versus wireless connections can make a difference.

There are a lot of variables you need to eliminate as potential sources.

TAC, as in our support: Contact Support | Check Point Software 

[Kraucer_Mazuco]

It should have no relation to these location or route variables. The problem always happens when I connect via VPN. When I use out of VPN the rate goes up again.

[dggdmn]

Hi,

Did you find a solution to the 50% drop in speed.  I have the same problem.

[dggdmn]

Has solution to the problem been found?

[Maarten_Sjouw]

When you make sure to use AES-128 or 256 encryption, this should be handled by hardware which is part of most of the later cpu's .

[dggdmn]

Would encryption cause a 50% drop?  Can a Checkpoint appliance restrict the amount of bandwidth each user is allowed?

[Timothy_Hall]

You have a sub-1500 MTU somewhere between the VPN client and firewall, which is causing packet loss since IPSec traffic cannot be fragmented in transit (has the DF bit set).  TCP eventually throttles down far enough such that everything fits without fragmentation, until it tries to speed back up at which point the packet loss returns.  TCP yo-yo's up and down at the low MTU size threshold with lots of packet loss and bad performance.  Look into TCP MSS clamping or force your transport protocol from IPSec to HTTPS/TLS if possible.  You can also try lowering the MTU on your Windows 10 NIC to 1400 but that may not necessarily fix the problem in both directions.

Also make sure you are using AES not 3DES for your encryption protocol as that will reduce the load on the firewall; not sure if using 3DES would be the sole cause of a 50% drop in performance but I guess it could if the firewall is already heavily loaded.

[dggdmn]

Thank you for your feedback.  I connected a laptop right outside the checkpoint so there were no other devices in between the laptop and the Checkpoint.  I received the same result?  

[Timothy_Hall]

How are you measuring your speed?

[dggdmn]

I have used the Speakeasy, AT&T and Spectrum test sites.    

[Selvaraj_Subram]

Hi,

We are also facing same problem. Within our on-premise network our speed is 88 Mbps download and 800 Mbps upload. But when we establish VPN connection, the speed drastically dropped down to 8.4 or 9.2 Mbps upload/download speed. It is really huge difference for our VPN users and it is not acceptable speed. Someone needs to address this problem. Solution is definitely needed. Please continue to share your ideas.

Thank you,

Selvaraj

[Timothy_Hall]

Firewall code version and Jumbo HFA level?

[Selvaraj_Subram]

Hi Timothy Hall,

Our Firewall code version is R80.10 (Jumbo hot fix take 189) Gaia Kernel Version: 2.6. Please let me know if I need to open ticket with checkpoint support to trace the issue. It affects all users no matter what location and what workstation/laptop they use. It is definitely biggest speed loss for us using checkpoint VPN. We are trying our best to find root cause but no luck so far. Thank you for looking into this.

[Timothy_Hall]

What VPN client are you using?  Endpoint Security?  Mobile Access Blade?

[Selvaraj_Subram]

What VPN client are you using?  Endpoint Security?  Mobile Access Blade?

Answer to your question:

1. We are using Endpoint Security - Version E80.87 (80.87.9201)

2. Yes, it is Mobile Access Blade.

I suspect that it is something to do with common configuration for all users. It could be Encryption or Authentication method or MTU setting needs to be changed. 

Kindly check this for me. It is frustrating low speed over checkpoint VPN for many users in our network.

Thank you

Selvaraj

[Timothy_Hall]

Endpoint Security uses IPSec for the transport instead of SSL/TLS, and as such can be affected by inconsistent MTU sizes.  Unfortunately you can't use SSL/TLS as the transport for Endpoint Security which is more tolerant of network conditions such as these.  Try this as a test:

1) Benchmark performance through the VPN.  Be sure to test and benchmark the speed of traffic through the VPN in both directions: upload a large file from the VPN client to the main network, and download a large file from the main network to the VPN client. 

2) On the VPN client, lower the MTU on the main LAN adapter from 1500 to 1360 using the instructions here: https://support.zen.co.uk/kb/Knowledgebase/Changing-the-MTU-size-in-Windows-Vista-7-or-8

3) Benchmark performance through the VPN again.  Be sure to test and benchmark the speed of traffic through the VPN in both directions: upload a large file from the VPN client to the main network, and download a large file from the main network to the VPN client.  Did the performance change substantially?  If it didn't, it is not a MTU issue.  If it did improve, it probably was only in the VPN client -> main site direction and if so it is definitely a MTU issue and we can discuss next steps.

[Henrique_Sauer_]

It worked in my case. I had an IPSec VPN with 3º Party in the branch office and CKP in the DC. Internet access from the Branch office behind the 3º Party is throughout the CKP GW in the DC, but when HTTPS was enabled in CKP the internet access from the branch office was really slow. I just decrease de MTU size in the client site (branch) and everything worked.

Thanks, TIM!

[Maarten_Sjouw]

The best way to solve this on a Site to Site VPN is by using MSS clamping. The actual MSS value depends on the type of VPN used.
Actually these are the simple steps that turn on MSS-clamping for VPN only:
Add this line to $FWDIR/boot/modules/fwkern.conf file and reboot: fw_clamp_vpn_mss=1
Add this line to $FWDIR/boot/modules/simkern.conf file and reboot: sim_clamp_vpn_mss=1
In GuiDBedit on the Network Object of the Cluster:
Set the item fw_clamp_tcp_mss_control to True
On the interface External set item mss_value to 1300 (safe value)
Now reboot the gateway and push policy.

PS to identify the correct MSS value you can use the free tool TCPoptimizer, test through the tunnel and MTU-40 (TCP & IP Headers) gives you the correct MSS value.

[Timothy_Hall]

Agreed, MSS clamping is the best long-term solution.  Lowering the MTU on an interface is just a quick and easy test to determine if inconsistent MTU sizes are impacting the performance of an IPSec VPN.

[Tim_McColgan]

This is still a major issue with Checkpoint to this day, and is rearing it's ugly head during Covid. Checkpoint is doing something to drastically decrease the bandwidth when remote access clients connect with VPN client. I am on version e83.20 and have experienced this for many years. TAC still can't solve it. 

[514numbers]

We have the same situation with R80.40 HFA83 with Endpoint VPN R83.30 with hub mode / desktop policy / SCV. We have opened a case as nothing seems to be working.