There was a fascinating story on TorrentFreak.com today extolling the virtues of VPNGate.net. It’s a project brought to us by the Graduate School of University of Tsukuba, Japan. Essentially, it offers free VPN access to anyone in need. The goal is to subvert censorship in the digital age. For example, Iran and China block access to YouTube, Twitter, and Facebook. But internet users in those geographic areas can bypass their nations network filters by configuring their computers to route all traffic through an internationally based Virtual Private Network, or VPN. For example, a Chinese college student could configure his laptop to use a VPN server in Japan. When that student’s VPN connection is properly configured, all network access will be tunneled though that VPN connection. Any web site he visits won’t show his Chinese ISP’s IP address in the logs. The logs will records the IP address of the VPN server in Japan.
At its most altruistic level, this is a tool of free speech. VPNGate.net offers a range of VPN server locations based in the United States, Canada, Japan, Russia, Italy, Czech Republic, and the UK. You literally select a desired VPN end point, configure your computer, and off you go! The project offers a wide range of VPN protocols as well. The tried and true L2TP/IPsec is supported, as is OpenVPN, as well as SSL-VPN. This means just about any personal computing device can use the service: Mac, Windows, Linux, iOS, and Android. The project’s web site has documentation explaining how to configure each operating system.
First and foremost, proper configuration of the VPN tunnel is absolutely critical. And I want to draw special attention to this point since many of the people who use VPN access on a regular basis don’t consider this. The computers VPN configuration has an option to “send all traffic over VPN connection.” Your OS might phrase it slightly different, but this is a critical setting. If you want to obscure your digital traffic to the greatest possible extent, this option must be engaged. If it is not, only some traffic will route over the VPN. The rest of the traffic will flow out through your internet connection in a traditional manner and it is neither wrapped in encryption nor routed through the the international network.
Several years back, a bug in the Macintosh operating system rendered the “send all traffic over VPN connection” option non-functional. Even when users selected the option, most traffic was not tunneled across the VPN. The bug didn’t get the sort of press it should have. In fact, almost no one noticed the issue. But, back then, VPN access wasn’t widely understood and few Mac users knew what it was, let alone that it was built into the OS. But since that day, every time I configure VPN access for a client, I make a point of manually checking the data’s route when the VPN is engaged. Simply put, you can’t be too careful. But keep in mind, the time it came to my attention it was an issue with the Macintosh. I guarantee other OS’s have had the issue at times over the years. The only way to be sure is to know how to confirm the patch data is taking.
I should take this one step further and clarify an important difference. Often times, in business, a mobile user will connect to a company’s network via VPN. Typically when that happens, the mobile users company specific data is routed over the VPN tunnel to the company network and the general, non-company specific internet traffic is routed out onto the internet as per usual, without going through the VPN. This reduces load on the company network and the VPN infrastructure. Only network data that is sensitive is routed over the secure VPN tunnel. In this configuration, it’s normal not to have the “send all traffic over VPN connection” enabled. It allows some data to go through the VPN and some to go over the internet as normal. It’s the people with something to hide or something to fear that will want to force all traffic through the VPN tunnel. For example, dissidents or political refugees communicating in secret. These are the people with something serious at risk if they think they’re communicating securely when in fact they are not.
So, the question becomes, how do you know? How do you know if all of your traffic is traversing the VPN tunnel. Checking the “send all traffic over VPN connection” option should be enough. But if the stakes are high, you’ll want to be sure. The good news is that its easy. On the Mac, just open the Network Utility application that comes with every install of the OS. Select the Traceroute tab at the top. Enter the address of a remote site on the web and hit trace. Ideally you’ll want to run one test before you engage the VPN tunnel. Select a specific site. I’ll suggest www.google.com as an example. Then click Trace.
The Traceroute tool will kick out many lines of information. You want to keep an eye on the first five or so. They will give you what you need to compare. You’ll be comparing the test you run without the VPN engaged to the results you receive after the VPN has been activated. Here’s my example:
traceroute: Warning: www.google.com has multiple addresses; using 184.108.40.206
traceroute to www.google.com (220.127.116.11), 64 hops max, 72 byte packets
1 10.0.1.1 (10.0.1.1) 0.424 ms 0.300 ms 0.230 ms
2 c-98-216-288-1.hsd1.il.comcast.net (98.216.288.1) 22.229 ms 26.856 ms 29.946 ms
3 te-7-5-ur02.mchenry.il.chicago.comcast.net (18.104.22.168) 10.106 ms 10.863 ms 9.654 ms
4 be-22-ar01.area4.il.chicago.comcast.net (22.214.171.124) 12.835 ms 15.432 ms 15.796 ms
traceroute: Warning: www.google.com has multiple addresses; using 126.96.36.199
traceroute to www.google.com (188.8.131.52), 64 hops max, 72 byte packets
1 public-gw.vpngate.net (10.211.254.254) 202.046 ms 183.478 ms 185.813 ms
2 192.168.254.254 (192.168.254.254) 231.327 ms 180.762 ms 183.711 ms
3 datacenter10gw.softether.co.jp (184.108.40.206) 187.141 ms 182.077 ms 185.486 ms
4 220.127.116.11 (18.104.22.168) 188.330 ms 185.901 ms 193.305 ms
I’ve boldfaced lines #1 and #2 in the before and after. They’re the important entires here. In the before example you can see how the data leaves my local network (the 10.0.1.1 addresses) and jumps right to the Comcast network. Comcast is my internet service provider.
In the after example, notice lines #1 and #2 are completely different. All I’ve done on my computer is engage the VPN connection. And all of the routing that appears on the traceroute results is completely different. Line #1 shows my traffic hitting the vpngate.net network first, then moving to another part of that network before moving through a router designated as datacenter10gw.softether.co.jp. This is in Japan, the location of my VPN connection.
The specific names and IP addresses shown in the traceroutes aren’t important. Each time I connect to the VPN in Japan, my path could change slightly. What is important here is the completely different path my data takes once the VPN is engaged. That’s how I know the tunnel is up, in place, and is routing all of my traffic over the VPN. If something were wrong, for example a bug in the software like the old version of the Mac OS where it said it was sending everything over the VPN when it really wasn’t? If that were the case the before and after results would look the same. Lines #1 and #2 of the traceroute would be the same whether the VPN was engaged or not.
There are a couple of additional observations we can make based on the results of the traceroutes. Possibly the most important of which is that the use of the international VPN adds latency and increases ping time. Those terms might not mean much to you at first glance. But when ping times go up and latency increases things like audio and video conferencing will get hosed very quickly. If you’re using a VPN and having trouble with Skype or Facetime, try killing the VPN and giving it another shot. Once that traffic isn’t being redirected all over the planet unnecessarily, performance will return to normal and the problem should be solved. Oh, but if you’re a political refugee, keep in mind that dropping the VPN tunnel to make that Skype call just made you a whole lot easier to track. It’s all a matter of tradeoffs!
My network throughput shifted dramatically when I engaged an international tunnel to Japan. The massive loss in performance is logical. Remember, I’m essentially routing all of my traffic to Japan before shooting every packet of it back to the United States. Then the return patch has to traverse to same route. Every packet, ever single byte of data…
The next set of problems is really more amusing than anything else. If you’re connecting to a foreign VPN and surfing the internet, get ready to see some really messed up ads. For example, when I connect to the VPN in Japan, many of the banner ads I see on the web now appear in Japanese. They are geo-targeted based on the IP address of my computer which is now showing that I’m located in Japan. Some sites will make incorrect assumptions about you as a person as well. For example, its likely that the Google.com page will now show all content in Japanese. If you pick one of the Russian VPN locations, you better be prepared to read Cyrillic!
And, last but not least, there are potential security concerns. Sure, you might be using the VPN tunnel to increase your security but you get what you pay for. By tunneling all of your traffic through the VPN, you’ve made the VPN provider your network endpoint. That means that, for all intents and purposes, your computer is plugged directly into their network on the other side of the world. It’s as if you used a single 7,000 mile long ethernet cable to plug directly into their server cabinet. From there, your network traffic passes through their router before going out onto the internet. But, if the VPN server is run by a less than scrupulous host, your network cable is plugged into their network and then all of your traffic is filtered and analyzed as it travels to and from your computer. That means, in theory, the VPN provider could be reading all the unencrypted data leaving or entering your computer. And don’t bet on your encrypted traffic being much safer. There are many forms of man in the middle exploits which can be used to attack the encryption used to secure your encrypted email or banking information!
Does that scare you? It should. You have no idea who’s hosting that VPN service. And keep in mind they’re doing it for free. Someone’s footing the bill for those bandwidth charges. What’s in it for them? In the case of the University of Tsukuba, Japan, it might be a purely academic pursuit. But who’s to say that’s the case with each of the VPN endpoint providers?
That said, there are VPN services you can pay for. They are much more likely to be on the up and up since they have a fiduciary incentive to play by the rules. I don’t have first hand experience with any of these 3rd party VPN services, but TrorrentFreak.com advertises for Privateinternetaccess.com and I’ve heard good things about Boxpn.com.
VPN access is a beautiful thing. And I love what VPNGate.net is doing by providing free access. In time, I think more and more of the communication the travels over the internet will be encrypted in one way or another. But its solutions such as VPN that allow people to encrypt what they want, when they want. And that’s good for everyone!
Update: 3/26/13 9:13am
A friend just sent me some speed tests run using his account on the Boxpn.com network. The performance is much more impressive, even though he’s connecting to a VPN in Germany!
Update: 3/29/13 2:45pm
Another reader emailed a speed test showing his VPN connection via Boxpn. This was also by way of Germany from the United States. There seems to be a trend developing!
Update: 4/2/13 9:47am
Another Boxpn user sent this bandwidth test comparing Frankfurt, Germany to Toronto, Ontario. At this point I would like to point out that Boxpn is not a sponsor of this post or this blog! Apparently it’s just popular!