I just noticed something curious. While I was in the middle of checking out my codebase from home, I VPN'd in to the office right quick and my SVN checkout speed doubled! Once I was done I closed the connection and my checkout speed dropped back down to where it had been.

What gives!? I was under the impression that VPN is way slower than HTTP is, and if I were to look at a website on my home PC while VPN'd in then the page takes way longer than not being connected to the work network. I dunno, this just seems strange to me, if anyone has any insight as to why this happened, I would appreciate it.

  • 1
    Tons of speculation could be made as to way this is. But yes. Generally speaking going through a VPN will add latency to a request, making it slower. There are exceptions, in the case of high-end vpn concentrators doing caching on both ends, etc. But randomly loading a web page through vpn will take longer. – Ryan Gibbons Jun 6 '11 at 4:39
  • Its also possible that the VPN is better tuned for LFN operations, and the DNS lookups may be more efficient, and it may bypass content filters..... – symcbean Jun 6 '11 at 12:50

To your first question: my bet would be that your ISP might be doing some sort of throttling of HTTP connections. When you're VPNed into work, that traffic gets encrypted and thus, is no longer subject to the ISP's throttling.

Regarding websites taking longer to load while VPNed in. This is a completely different use case, and the slowness is not caused by the VPN itself. It sounds like your workplace has the VPN set up to route all traffic over the VPN tunnel while connected. This means that when you request a website, the request gets routed over the VPN, then out through whatever internet link your work has to the remote webserver. Then the reply has to take the same path back, through your work's network and then back through the VPN tunnel. It is these additional routing hops that cause the slowdown. With your SVN checkout, the data is going direct from your workstation to your work network whether it's direct over the internet or through the VPN.

  • Even with a business plan, they would still throttle our http connections? I wasn't around when we signed up with our ISP, but I would imagine a business plan with any ISP that includes a static IP address would mean they are allowing us to host some of our own services on our network. – Bender the Greatest Jun 6 '11 at 4:01
  • And secondly, I'm aware of tunneling all network traffic through the VPN. It's not really an issue per-se, just that I haven't looked into how to tunnel only the intranet traffic through the VPN. IT work takes second place to programming, so my boss just wants it to work, even if its at an inconvenient stage. – Bender the Greatest Jun 6 '11 at 4:05
  • I was speaking of your home ISP doing the throttling. Unless you have a business-class connection there as well. – EEAA Jun 6 '11 at 4:06
  • 1
    The term you want to search for when researching how to only route intranet subnets over your VPN is "split tunneling". – EEAA Jun 6 '11 at 4:07
  • 1
    Split tunneling most definitely does not require two network adaptors. – EEAA Jun 6 '11 at 4:14

Despite being an old question I stumbled here and I can see a lot of speculation here. The other answers are likely correct to some extent, but I believe it misses the crucial factor for the situation experienced by the asker.

VPN uses compression.

I'm using LZO-compression and that will improve my speeds up to 4x compared to the connection width. This is particularly noticeable using speed tests or when downloading/uploading easily compressible data such as csv-files. In my case this applies to openvpn Home-Office connections as well as to the service I'm using Private Internet Access.

Note that not all VPN-connections have compression enabled, however they all (should) have encryption enabled. Adding or turning on compression will have marginal impact on cpu-cycles and latency and possible improvement with throughput and large packet latency.

Requirements for the event to happen

  • The VPN-tunnelling is active over the slowest part of the end-to-end traffic. Ie. two fast separate local area networks are bridged (connected) using a VPN. This VPN is active over a slower part of the network (internet).
  • VPN-tunnel compression is ON
  • The transferred data moving in the VPN-tunnel is not already compressed (such as picture files) or encrypted (sending eg. email)
  • The speed is constrained by the bandwidth, not by the sending/receiving end
  • +1. Exactly. Not every (most not) web server compresses the outgoing data (HTTP has support for negotiating a compression format). So a VPN that compresses can increase effective bandwidth if the other end point has a larger bandwidth (such as a VPN host at a data center). – TomTom Jun 10 '14 at 11:28
  • It is important, of course, to be careful of vulnerability to CRIME-like attacks. If the attacker has any control over the packet contents, this can be a problem. – Falcon Momot Sep 30 '15 at 2:28

There's two common reasons for this, and they both involve the configuration at your work:

  1. Their VPN and their HTTP are running on totally different connections. You work might have a dedidcated SDSL line for VPN traffic, and a slower ADSL line for HTTP

  2. VPN traffic has a much higher priority on your gateway than HTTP traffic. Here we have a lot of rules regarding which protocols get higher priority. Inbound HTTP is one of the lowest, as we only host internal, throw-away solutions. VPN traffic is 2nd highest (after VoIP being the highest). We also throttle HTTP connections to 2Mbps/total, VPNs are throttled to 5Mbps/each

Either way, it's not because the VPN is inherantly faster, it's because the config has made HTTP slower.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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