8

I'm trying to troubleshoot an extremely slow file transfer (5kb/s up) to a work server over the VPN.

A network admin at work has told me that I should expect to see a transfer rate reduced by up to 55% when I am connected to the VPN at work. I realize there are a lot of variables here, but is that figure typical? I did a speed test at BandwidthPlace before and after connecting the VPN and didn't see any appreciable change. Is that a reliable test?

We are using Forticlient SSL VPN.

jcollum
  • 436
  • 2
  • 5
  • 16
  • What type of file transfer? HTTP download, FTP, SMB? – joeqwerty Oct 18 '11 at 19:23
  • @joeqwerty maybe none of those? Not sure. I'm using a powershell script to transfer files to a UNC share from my machine over the VPN connection – jcollum Oct 18 '11 at 21:03
  • 1
    Well then that's SMB. As Zoredache mentioned in his answer, SMB doesn't lend itself well to connections with higher latency than a LAN connection. As an unscientific example, it took 49 packets to transfer a 1KB file via FTP and 196 to transfer the same file via SMB. – joeqwerty Oct 18 '11 at 23:00

4 Answers4

8

Assuming you have a sufficiently fast processor on both ends of the device terminating the VPN, you shouldn't see much of a change in throughput at all. Throughput is the amount of data that can be transmitted during a certain amount of time.

Most VPNs do not really drastically change the size of the payload, and don't add that much additional overhead. An overhead of 10-15% might be reasonable, but a 55% overhead is not.

What is more likely is that your VPN is simply increasing the time it takes for a packet to be transmitted from the source to the destination. Additional latency can make certain protocols perform worse. Windows file sharing (CIFS aka SMB) is extremely sensitive to latency.

If you are trying to use CIFS over a VPN, you basically have to give up on the idea that you will be able to see your full capacity used.

Probably the best tool to test performance is iperf.

Zoredache
  • 131,987
  • Agree with Zoredache. When I used Fortigate SSL VPN, CIFS was terribly slow since it's very chatty-queue-chatty. My suggestion would be to allow remote desktop connections to a well regulated location (over the VPN) and have your user(s) work on files locally. This is much better for security, latency, and end user happiness. – brandeded Oct 18 '11 at 20:35
  • While Zoredcache usually gives good answers, this is not one of them. Running a tunnelled connection over a high BDP network creates al sorts of problems with bandwidth management - the inner connection can't see what is being negotiated on the outer connection. You will probably find that if you run multiple connections concurrently you'll get very close to the bandwidth of an unencrypted connection. – symcbean Jul 13 '19 at 19:32
  • @symcbean keep in mind the age of this answer I provided. At that time server 2003//XP and older versions of Windows was still common. Meaning people didn't have SMB2/SMB3 which dramatically improved CIFS/SMB performance. Sure a tunnel does change some things, but SMB, which the OP was asking about, tended to be far worse compared what you would expect from simple benchmarks. – Zoredache Jul 15 '19 at 05:10
2

There are a number of factors that can affect VPN slowness. Most (if not all) are out of your control. If your connection is fine outside of a VPN connection, what does that tell us about VPN? Either we have a software issue (a configuration setting, potentially conflicting software, maybe a software firewall or a over-eager security app.) or we have some sort of network slowness. Beyond the local workstation and connection, there are other major factors. While ISPs will deny this, VPN traffic can be demoted... especially if you're not paying for a business connection. I may get some arguments from people with that comment, but I've seen it happen first-hand. Also, your Network Admin's VPN could be outdated, overloaded, or simply just not configured as well as can be.

To answer the BandwidthPlace question: No. That's not a good test.

Some VPN connections force users to funnel ALL traffic through the VPN, even locations outside of the destination VPN. In english: If you browse to serverfault.com without VPN: you go from your connection through your ISP to serverfault and back again. Using VPN, if you browse to serverfault.com, you go from your connection through your ISP to your business then to their ISP to serverfault.com and back again. That's a ton more hops! Ask your Network Admin if they have Split Tunneling enabled. This allows some non-business traffic to pass normally and not through the VPN connection.

Ben Campbell
  • 567
  • You're correct, split tunneling is enabled. Which makes the bandwidth reduction that I'm seeing seem even more odd. – jcollum Oct 18 '11 at 18:06
  • hrm, traffic filtering? does your connection also support VOIP? If it does, it could be due to traffic shaping to maintain decent VOIP throughput. – Ben Campbell Oct 18 '11 at 18:09
  • nope, no VOIP on my end of the connection – jcollum Oct 18 '11 at 21:04
  • Are there lots of concurrent connections through the VPN? Have you noticed a difference in performance based on time of day? – Ben Campbell Oct 18 '11 at 21:15
  • Well I only really connect in the evening (8PM or after) or in the early morning (7AM). Haven't noticed any time dependent changes. There's not a lot of remote workers in our org, so traffic shouldn't be a huge factor. – jcollum Oct 18 '11 at 21:49
  • what kind of traffic are we talking? what applications are you using? i'm gonna guess the typical office stuff. I used to work for a hospital and we pushed huge data over the VPN in the form of test results (imaging, video, etc.) The extra hops made it feel awful despite our best efforts. – Ben Campbell Oct 19 '11 at 14:11
2

This is hardware dependent, but VPN connections can suffer reduced performance for reasons that aren't purely bandwidth related. I used to manage an older cisco VPN concentrator and it worked fine but began to degrade in performance over time. It ended up that, even though the device had plenty of raw bandwidth, the CPU could only handle about 4Mb/s traffic before it began to noticeably degrade in performance. This could either happen through a surge in normal traffic (for instance, a blizzard causing many more users than normal to be online at the same time) or through something like a single user with a large pipe at home saturating the CPU with a sustained copying of large files.

So, yes it's feasible that there's an explanation for why you feel a slow down over the VPN, but that doesn't really explain why the admin had a number like "55%" ready for you.

jj33
  • 11,268
1

Very little to none for modern hardware. The problem is that you're using the remote gateway (it sounds like) and you'll get a speed hit because you're now going through yet another bottleneck before getting on the internet. So if you have a fast 50/10 line at home but your VPN provider has a 5/1 line, then all you're getting at most is 5/1. If that 5/1 is 50% utilized all the time then you're getting 2.5/512k.

Also SMB1 file transfers never seemed to work right over VPN because MS never made it a priority. SMB2 is supposed to resolve this. Maybe he meant this.

DrZaiusApeLord
  • 1,194