Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
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
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
up vote 5 down vote accepted

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.

share|improve this answer
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. – mbrownnyc Oct 18 '11 at 20:35

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 without VPN: you go from your connection through your ISP to serverfault and back again. Using VPN, if you browse to, you go from your connection through your ISP to your business then to their ISP to 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.

share|improve this answer
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

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.

share|improve this answer

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.

share|improve this answer
How does Split Tunneling factor in to the first paragraph? – jcollum Oct 18 '11 at 21:11

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.