Kamil Choudhury

#define ZERO -1 // oh no it's technology all the way down

OpenVPN In A Time Of Deep Packet Inspection

I tunnel some (not all) traffic on my home network in Qatar through an OpenVPN server in the US. The reasons are completely un-nefarious: I have a couple of dev servers in a colo in New York that I didn't feel like uprooting and bringing to Qatar, so I now need to bridge my home network to the US so that I can still access my files. Fair dinkum.

Within a few moments of connecting to my US OpenVPN server, I noticed this in the server logs:

Aug 24 06:55:50 installation00 openvpn_tap0[92375]: TCP connection established with [AF_INET]ww.xx.yy.zz:61813
Aug 24 06:55:52 installation00 openvpn_tap0[92375]: ww.xx.yy.zz:61813 WARNING: Bad encapsulated packet length from peer (18245), which must be > 0 and <= 1579 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]
Aug 24 06:55:52 installation00 openvpn_tap0[92375]: ww.xx.yy.zz:61813 Connection reset, restarting [0]

The client configuration worked fine in the US, so the warning about an active attack is not a red herring: the local telco clearly recognizes OpenVPN connections and attempts to scupper them.

The next move in the standard playbook is to sheathe the VPN connection in something less suspicious. While tunnelling OpenVPN inside stunnel results in a viably stable connection, it is clear that the telco knows something fishy is going on. Here are the results of an iperf of the VPN's bandwidth on a connection that is nominally rated 30/5Mbps:

[ ID] Interval Transfer Bandwidth
[ 4] 0.0-60.4 sec 1.03 MBytes 144 Kbits/sec
[ 6] 0.0-60.6 sec 7.87 MBytes 1.09 Mbits/sec

Fortunately, git clone does not need much bandwidth, so I am happy living with the slow connection for now.