VPN download speed is very slow on Linux if comparing to the same download file on Window

[lapth]

Hi,

My download speed is very slow on Ubuntu 18 LTS if comparing to Window 10

My test is very simple:

1. On Window 10, after connected to VPN, I download one repository from github.com, it takes about 5 minutes

2. On Ubuntu 18 LTS, after connected to VPN, I download the same repository, it takes more than one 30 minutes then failed 😞

Please help.

Thanks

[PhoneBoy]

What VPN clients are being used at which version of said clients?
What version/JHF is the gateway?

[lapth]

Thanks PhoneBoy,

I am using this:

OS:

Distributor ID: Ubuntu
Description: Ubuntu 18.04.4 LTS
Release: 18.04
Codename: bionic

SNX: tried with many versions

Check Point's Linux SNX
build 800008074

How can I check the gateway version from the Client side?

[PhoneBoy]

If you don't have access to the gateway, there's not much you can do on the client side.
Are you using SNX on Windows as well or some other client?

[lapth]

On Windows, I am using the E82.50_CheckPointVPN.msi no problem with this version.
On Linux, I am using snx_install.sh (download from gateway), I am able to connect to gateway with cmd like this: snx -s <IP> -u <userId>

[PhoneBoy · Accepted solution]

These clients operate and impact the gateway very differently.
The Windows VPN client is operating using IPsec, which the gateway can process relatively efficiently thanks to SecureXL.
SNX operates over HTTPS and terminates on a specific process on the gateway, meaning all traffic is effectively F2F (slowpath).
As a result, a given gateway can terminate far more Remote Access users using the regular VPN client and achieve significantly better performance versus using SNX to perform the same task.

In other words, this is probably expected behavior.

[Timothy_Hall]

I agree with Phoneboy that there is a difference in overhead incurred by the two different VPN clients, but that yawning chasm between performance levels seems way too large to account for all of the VPN client implementation differences.  A few things to check:

1) Are the Windows system and the Ubuntu system on the same VLAN with the exact same network path between them and the firewall where the RA VPN is terminating?  If not you need to do this for your testing to eliminate any intervening network differences due to MTU sizes, packet latency/loss etc. which can dramatically impact performance.

2) Next step is to ensure the Ubuntu box itself is not experiencing any localized NIC issues.  Run netstat -ni and make sure that ERR/OVR/DRP counters are zero or very close to zero, and especially that they not actively incrementing during your VPN performance test.

3) During a VPN performance test run top on the Ubuntu box and hit 1.  While traffic is transferring are any CPUs running at 100%?  I'm not sure if the Linux SNX client is multithreaded, but if a CPU is saturated that indicates a CPU bottleneck.  (this situation is pretty unlikely but needs to be checked anyway)

4) Next step is prior to a VPN test, run netstat -s on the Ubuntu box and note ICMP & TCP counters reported (also try netstat -svv and netstat -see to determine if you can get verbose/enhanced protocol statistics on that version of Linux).  Run your VPN test for about 5 minutes then stop it.  Run netstat -s again and compare the ICMP/TCP counters.  Retransmissions?  Bad segments?  Any suspicious ICMP counters increment significantly like Source Quench, Dest Unreachable?

5) Final step if the problem still persists is to take a packet capture on the Ubuntu box with tcpdump -w (filename) while a VPN transfer is running, then pull that capture into Wireshark for analysis.  Wireshark does a great job of highlighting retransmissions, TCP zero window events, and other network conditions that can kill performance and help get you pointed in the right direction for remediation.  One thing to be on the lookout for is long inter-packet delays, and which side then finally speaks up to break the logjam and get things moving again.  Especially look for long delays where your VPN client is waiting for the firewall to do something, or perhaps vice-versa, and at least you will know which side is holding things up and you can focus your investigation there.

Good luck!

[lapth]

Thanks for your detail, in fact I am on the same network, I have tested with a Windows Virtual Machine on Ubuntu host, it works well too so this should be the problem of SSL VPN.