Douglas Crawford

Douglas Crawford

May 17, 2013

As internet censorship tightens across the world, governments are becoming more and more concerned about preventing the use of VPN to circumvent their restrictions. China, with its Great Firewall, has been particularly active in this regard, and there have been many reports of VPN into and out of China being blocked.

The problem is that while it is impossible to ‘see’  the data in an encrypted VPN tunnel, increasingly sophisticated firewalls are able use Deep Packet Inspection (DPI) techniques to determine that encryption is being used (to detect for example the SSL encryption used by OpenVPN).

There are a number of solutions to this problem, but most of them require a degree of technical expertise and server-side configuration, which is why this article is simply an introduction to the options available. If hiding your VPN signal is important to you and Port 443 forwarding  (see below) is insufficient, then you should contact your VPN provider to discuss whether they would be willing to implement one of the solutions outlined below (or alternatively find a provider, such as AirVPN, who already offers this type of support).

Port Forward OpenVPN through TCP port 443

By far the simplest method, one that can be easily performed from your (the client) end, requires no server-side implementation, and will work in most cases, is to forward your OpenVPN traffic through TCP port 443.

OpenVPN by default uses TCP port 1194, so it is common for firewalls to monitor port 1194 (and other commonly used ports), rejecting encrypted traffic that tries to use it (or them).  TCP port 443 is the default port used by HTTPS (Hypertext Transfer Protocol Secure), the protocol used to secure https:// websites, and used throughout the internet by banks, gmail, twitter, and many more essential web services.

Not only is the use of OpenVPN, which like HTTPS uses SSL encryption, very difficult to detect over port 443, but blocking that port would severely cripple access to the internet and is therefore not usually a viable option for would-be web censors.

Port forwarding is one of the most commonly supported features in custom OpenVPN clients, making changing to TCP port 443 ridiculously easy. If your VPN provider does not supply such a client, then you should contact them.

Unfortunately, the SSL encryption used by OpenVPN is not exactly the same as ‘standard’ SSL, and advanced Deep Packet Inspection (of the type increasingly used in places such as China), can tell if encrypted traffic conforms to the ‘real’ SSL/HTP handshake. In such cases alternative methods of evading detection need to be found.

Obfsproxy

Obfsproxy is a tool designed to wrap data into an obfuscation layer, making it difficult to detect that OpenVPN (or other VPN protocols) are being used. It has recently been adopted by the Tor network, largely as response to China blocking access to public Tor nodes, but it is independent of Tor, and can be configured for OpenVPN .

To work, obfsproxy needs to be installed on both the client’s computer (using for example port 1194), and the VPN server. However, all that is then required is that the following command line be entered on the server:

obfsproxy obfs2 –dest=127.0.0.1:1194 server x.x.x.x:5573

This tells obfsproxy to listen on port 1194, to connect locally to port 1194 and forward the de-encapsulated data to it (x.x.x.x should be replaced with your IP address or 0.0.0.0 to listen on all network interfaces). It is probably best to set up a static IP with your VPN provider so the server knows which port to listen in on.

Compared to the tunnelling options presented below, obfsproxy is not as secure, as it does not wrap the traffic in encryption, but it does have a much lower bandwidth overhead since it is not carrying an additional layer of encryption. This can be a particularly relevant for users in places such as Syria or Ethiopia, where bandwidth is often a critical resource. Obfsproxy is also somewhat easier to set up and configure.

OpenVPN through an SSL tunnel

A Secure Socket Layer (SSL) tunnel can, on its own, be used as an effective alternative to OpenVPN, and in fact many proxy servers use one to secure their connections (an article on setting this up is available here). It can also be used to completely hide the fact that you are using OpenVPN.

As we noted above, OpenVPN uses a TLS/SSL encryption protocol that is slightly different from ‘true’ SSL, and which can be detected by sophisticated DPI’s. In order to avoid this, it is possible to ‘wrap‘ the OpenVPN data in an additional layer of encryption. As DPIs are unable to penetrate this ‘outer’ layer of SSL encryption, they are unable to detect the OpenVPN encryption ‘inside’.

SSL tunnels are usually made using the multi-platform stunnel software, which must be configured on both the server (in this case your VPN provider’s VPN server) and the client (your computer). It is therefore necessary to discuss the situation with your VPN provider if you want to use SSL tunnelling (a setup guides is available here for reference), and receive configuration instructions from them if they agree. A few providers offer this as a standard service, but AirVPN is the only one we have so far reviewed (anonypoz being another).

Using this technique does incur a performance hit, as an extra layer of data is being added to the signal.

OpenVPN through an SSH tunnel

This works in a very similar way to using OpenVPN through an SSL tunnel, except that the OpenVPN encrypted data is wrapped inside a layer of Secure Shell (SSH) encryption instead. SSH is used primarily for accessing shell accounts on Unix systems, so its use is mainly restricted to the business world, and is nowhere near as popular as SSL.

As with SSL tunnelling, you will need to talk to your VPN provider to get it working, although AirVPN supports it ‘out of the box’. SSH tunnelling uses the PuTTY telnet/SSH client, and a relatively simple setup guide can be found here.

Conclusion

Without very deep packet inspection, OpenVPN encrypted data looks just like regular SSL traffic. This is especially true if routed via TCP port 443, where a) you would expect to see SSL traffic and b) blocking it would hamstring the internet.

However, counties such as Iran and China are very determined to control their population’s uncensored access to the internet, and have put into place technically impressive (if morally objectionable) measures to detect OpenVPN encrypted traffic. As even being discovered using OpenVPN can get you into trouble with the law in such countries, it is in these situations a very good idea to use one of the additional precautions outlined above.