Is this really true? My intuition is that something like speedtest.net would be measuring performance between the final client (i.e. the web browser in the home) and the final server (i.e. the speedtest.net server itself). I couldn’t find anything online to convince me that my intuition was false.
So if you’re on the work VPN the connection measured would be <home> -> <VPN> -> <work> -> <big scary internet> -> <speedtest.net>. I’d welcome an expert in the field to show me I’m wrong, because I’m genuinely interested in the mechanics of a test that measures only between speedtest.net and the work machines.
In my online search I did come across some potential reasons why a VPN might appear faster than a native connection:
The VPN supports data compression, meaning despite the VPN overhead you’re sending and receiving much less data over the slow home to ISP wires and consequently seeing faster speeds.
The VPN connects to a much faster DNS server than the one you’re configured to use when connecting directly through your ISP.
Again, I’m no expert, but perhaps there are some plausible reasons why this might be happening.
I just ran into this blog post, which talks about many of the issues related to testing VPN speeds: “Testing VPN speeds – an overview”. It mentions the compression issue.
I should note that I’ve actually had non-VPN related experience with this. The Comcast DNS server was experiencing major issues (congestion?) and browsing was incredibly sluggish. Changing to an alternative DNS server (I think I used a Google server) solved the sluggishness. Perhaps you inadvertently did this by using the VPN.
The ISP is doing some kind of dodgy manipulation of web traffic, perhaps injecting ads into web pages. The overhead from the packet inspection and web page modification is cutting into transfer speeds. Somehow, the VPN blocks this process. Maybe the ISP looks at the first packets between StG’s home and the office VPN, determines that they’re encrypted, and stops manipulating all future VPN traffic.
The ISP has quality-of-service (QOS) rules that prioritize VPN traffic over web traffic. In a sense this is also traffic manipulation, but it’s common, above board, and the sort of thing that business customers are willing to pay good money for. A mom-and-pop rural ISP might have set up the QOS rules to prioritize all VPN traffic, rather than VPN traffic to a particular business.
Many companies reroute your browser through a proxy server when you connect with a VPN. This serves many purposes; theoretically you’re using the VPN for work so they’ll want to filter out inappropriate web sites. Also, connecting via the VPN gives you direct access to company resources, and if you visit a malicious web site your PC acts as a conduit between your company’s systems and that malicious site. A proxy using a filter blocks those sites, protecting your company.
If you use Speedtest through a proxy server it will test the internet speed of that server and its ISP, not your computer and your ISP. Because you’re not really on the Internet, you’re looking at web pages being shown to you that the proxy server has downloaded for you. That’s how proxy servers work.
This is a pretty good hypothesis. I agree with Driver8 that speed tests should measure end-to-end bandwidth. I don’t know how they even could measure only speed-test-server-to-VPN-endpoint bandwidth.
Another thing that could be happening is related to what a lot of end users saw back when Comcast was intentionally congesting their interconnects with Netflix - using a VPN redirected traffic from congested interconnects to relatively open ones, creating a much faster experience (and less buffering!) If, for some reason, the interconnect between the OP’s ISP and the speed test server he’s hitting is particularly congested, he might a) be getting generally faster speeds than the speed test is showing and b) when using the speed test through an ISP, he’s showing the actual speed that his ISP provides him.
The proxy isn’t going to execute a bunch of client-side code on your behalf, though, which I presume is a necessity for calculating your actual speed. In other words, your end client is still going to have to pull down a bunch of bits from the speed test server (via the VPN), and then divide how many over unit time. This isn’t going to be done on the proxy. The proxy may serve up the HTML code for the page and assets, but that isn’t going to change the outcome of the speed test.
Let’s put it this way, I’ve done Speedtest through a VPN at a previous job, and it estimated that my closest router was down in California. I live in the Seattle area, but that company’s Internet gateway was in California (through a WAN). If I used Speedtest normally it would ping up where I lived. Whether or not the proxy was executing code, Speedtest was using that company’s gateway for the test, not mine.
I don’t think anyone is disputing that the bits used in the speed test are routed through your company’s gateway. We’re claiming that the download and upload speeds are calculated by client side code running in your browser, and are calculating how long it is taking for the bits to get all the way from speedtest.net to your browser.
I’m with Driver8. For the purposes of the speed test, it should still measure how fast is the download/upload between the client browser and the speedtest server. Having the traffic going through the VPN doesn’t change this and really ought to only slow things down, if anything. I don’t see how the 30Mbps reading could between the VPN proxy server and the speedtest server only – it would have to cut out the leg between the browser and the VPN proxy. Which is impossible, because it’s the client browser that’s initiating the download/upload and receiving/sending the bits.
Right - if you’re connected to your company’s VPN in California, you’ll appear to speed test as if you are in California, but your VPN will still route every single bit back to your computer in Seattle, which then calculates your bandwidth. ETA: The bits would originate in California, which may make your connection slower, since they have to are more likely to experience some bottleneck along the way. There are a lot of other variables, though, so it’s certainly possible you’d actually see your speed improve.
I’m not convinced you haven’t got something running that’s bogging things down when not connected to vpn that’s being short-circuited by the vpn software when it is connected. I’d download a run-from-cd version of Linux and create a boot disk to run the test from. You don’t need to be any kind of Linux guru to do that because most distros have a nice graphic front end on them these days. I’d recommend Ubuntu, but my experience is several years out of date so there may be something better available.
So I went to look at what speedtest actually tests as I could see this going a couple different ways and my initial guess was wrong. According to the speedtest website:
Note, his computer will only appear as coming from his company if they are not using a split tunnel.
[WAG]
I suspect that the ISP is traffic shaping using packet inspection and throttling that way. The VPN traffic is encrypted and the ISP can’t tell what the heck it is so it isn’t throttled.
[/WAG]
I tested this last night, going to the speedtest.net website from two computers, both with wired network connections and one on a VPN. The one on the VPN scored 4.58 Mbps while the other one scored 5.08 Mbps. So the VPN connection was actually slower.
I do count that as illegal, yes. That’s why it surprises me - I haven’t heard of any ISPs blatantly ignoring the net neutrality rules. Most of what I have heard centers around companies like T-Mobile, who are testing the edges and limits of net neutrality (T-Mobile’s argument, which I don’t agree with, is that by having an opt-out of the video ‘optimization’, a long with a completely open Binge-On program, they are compliant with net neutrality. We’ll see if the FCC agrees.)
Actually, I didn’t think through my last post well. That’s what I get for posting while working on another bandwidth issue*…
I don’t think net neutrality would enter the picture at all.
StGermain buys a 5 meg circuit. The circuit is actually capable of 100 megs. So, since it is supposed to be a 5 meg circuit, they throttle it down to the correct speed. All is good.
Except the throttling is done by traffic shaping specific protocols. VPN isn’t included. Therefore the VPN traffic gets higher speed on the circuit.
Of course, this is a WAG and not particularly well thought out.
Slee
*Got a new circuit in our data center. 100 meg. Fiber from the provider with a drop in our rack. Drop to fiber/ethernet media converter to router. Circuit is wayyyyy slow and dropping packets like mad. Huh? Interface on router at 100 full. Confused. For shits and giggles I set the router to auto/auto. Bing! Everything works. Set interface to 100/Full. It stops working. Set router to 100/auto. Bing, we are up again. The interface reports 100/Full duplex. So there is something going on with the media converter that I just don’t care enough to research as the circuit is up and working.