Slashdot linked to an article on China restricting VPN access, in particular OpenVPN clients. (Also: OpenVPN’s forums has a similar report) The problem seems to be they’ve implemented some sort of protocol detection that’ll flag and block OpenVPN connections after a while. Unfortunately, this is no longer an academic problem for me, since I’ve got a good friend who’s going to be spending a few months in China on a university exchange program; and Facebook/Skype/possibly FaceTime are all blocked.
I originally planned on setting up TunnelBlick (since said friend is using OS X) with the same OpenVPN profile that I’m using, but the changes to the Firewall means that I need to implement some sort of workaround beyond changing the port to something other than the default (which I anticipated they’d already be blocking the default 1194 – if they weren’t I’d be surprised).
The fixes that I’ve found seem to center around two things: move OpenVPN to a random port, or use TCP, or a combination of both. The best ‘source’ I’ve found is, surprisingly, a VPN provider’s page. (It’s surprising because I’d consider this to be a unique selling point, and so they wouldn’t publish it, but thankfully they’re using it to communicate with their customers.) Another VPN provider also has China-specific config files using TCP on port 443, so that’s something I’ll likely be doing. (Even though tunneling TCP within TCP is a bad idea, I’ll take slow connectivity over no connectivity.)
So I’ve ended up with two things to try: Run OpenVPN on TCP, and have OpenVPN listen on multiple ports. Right now I’m planning to get a second instance of OpenVPN running using TCP (I’m hoping it’s just copying the conf file and changing proto udp to proto tcp, but there’s probably a bit more to it), and get iptables to redirect incoming connections on all ports higher than, say, 10000, to the respective OpenVPN UDP/TCP ports. (I’m still not sure how to do this, it’ll be an exercise in Google-fu and experimentation.)
Thankfully, on the client side, ServerFault has an answer that looks good – namely, defining a bunch of IP address:port combinations in the OpenVPN config file using the syntax, and switching between them with –remote-random, so if one is blocked, it’ll fall through to another hopefully unblocked ip/port combination.
I’ll also look at varying the MTU settings so if it is protocol based, individual packets shouldn’t look like the OpenVPN protocol, and hopefully will escape detection. Also, running everything through stunnel. And as a final alternative, free VPN services like VPNBook, though I doubt they have the time & staff capable of changing stuff for residents of China.
I’m also hoping that this will blow over, and China will revert to a more relaxed stance after the leadership transition, but it never hurts to be prepared…
#1 by Chuck on December 26, 2012 - 3:00 am
I’ve been using OpenVPN with my own server in the US, and I’ve tried most of the things you suggested, i.e. TCP and a non-standard port. I originally used port 80, but I’ve been having to switch ports every day, because they’re pretty consistently blocking the old port every day. (UDP packets are completely blocked, with TCP they spoof reset packets.) They haven’t blocked traffic to the whole IP address though. It’s very odd. I’m not sure why.
Anyway, I need to look more closely at the OpenVPN spec and see what’s making it so simple to identify the OpenVPN packets. If you have any ideas or find a good solution, let me know!
#2 by Kyle Lexmond on December 26, 2012 - 11:56 am
I’m guessing it has something to with the OpenVPN protocol (scroll down) not being pure SSL, and so packets can be detected somewhat easily – and DPI would make it trivial once you know the packet format, which is easy to get from the OpenVPN source.
I’m thinking switching to TCP over stunnel on port 443 would probably work – that should make it appear like standard HTTPS, and hopefully fly under the protocol detection.
Out of curiosity, how long does it take before the port is blocked? If it’s just once a day, it’d be easy to just set up a port forwarding rule to forward a range of ports to the OpenVPN port, and then just setup a bunch of connection profiles in the OpenVPN client conf file. (Also, I’m assuming you’re using Amazon EC2 – how is it working out?)
#3 by Colin on December 31, 2012 - 3:23 am
Good posts on this subject. I intend to set up OpenVPN on a friend’s router in the UK next year when I travel back from China – your website will be very handy when that time comes.
For what it’s worth, Skype/FaceTime are not blocked in China (yet).
#4 by Kyle Lexmond on December 31, 2012 - 10:31 am
Glad to hear that it’s useful – I’d be interesting in hearing how it works out for you.
And thanks a lot for the info re Skype/FaceTime – that should make stuff somewhat easier.
#5 by Chris on February 11, 2013 - 7:01 am
Hi. Try Tor Obfuscating tool. I use that with success, and new filters are coming. It’s slow but working. Also OPenVPN seems to be the least accessible at the moment. I guess they found out that blocking PPTP, will disrupt alot of big companies daily work…so that is a better way to go…
#6 by Shawn on February 23, 2013 - 10:14 am
I’m sorry to report that OpenVPN on TCP 443 does not work any more. Apparently they now have the capability of telling OpenVPN packets from other SSL encrypted packets. I’m afraid it’s time to give the good ol’ PPTP or L2TP/IPSec a try.
#7 by Aboud Dee on February 28, 2013 - 2:27 am
Why the fixation on OpenVPN? Why not use SSTP?
#8 by Kyle Lexmond on March 2, 2013 - 8:46 am
Because I started out with OpenVPN for my own use (reading a few guides made OpenVPN sound trivial to implement compared to other VPNs), and I just scaled it out.
However, I’m looking at PPTP and L2TP, and now SSTP too, so thanks for pointing that out!
#9 by Aboud Dee on March 2, 2013 - 11:24 am
Here in the Middle East, my work takes me to alot of countries. All the ones that block VPNs have managed to block PPTP and L2TP, and most have managed to block OpenVPN. Not one has managed to block SSTP.