Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
lapth
Explorer
Jump to solution

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

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

0 Kudos
1 Solution

Accepted Solutions
PhoneBoy
Admin
Admin
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.

View solution in original post

0 Kudos
7 Replies
PhoneBoy
Admin
Admin
What VPN clients are being used at which version of said clients?
What version/JHF is the gateway?
0 Kudos
lapth
Explorer

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?

0 Kudos
PhoneBoy
Admin
Admin
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?
0 Kudos
lapth
Explorer
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>
0 Kudos
PhoneBoy
Admin
Admin
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.
0 Kudos
Timothy_Hall
Champion
Champion

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!

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
lapth
Explorer

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.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events