Monthly Archives: January 2015

Unitymedia is blocking VPN connections

unitymedia is a German ISP, and I made the unfortunate choice of using them as my internet service provider.

Unfortunately, they’re not a very good ISP, because they are using deep packet inspection (DPI) to throttle or block VPN connections. I would expect this sort of behaviour from certain countries (a full list of countries engaging in internet censorship can be found here) but never in Germany.

Obviously this claim cannot be made lightly. There must be some sort of proof to back up anyone who is claiming that a German ISP is filtering customer’s internet connectivity.

Could this be a mistake?
Possibly. Unitymedia does not have enough IPv4 addresses to give each customer a global IPv4 address. They are instead using something called DS-Lite in which each customer has a unique IPv6 address, and IPv4 connections are tunneled over IPv6 (4in6) to the carrier where customers then must go through carrier-grade nat (CGN) before reaching the internet.

Other people have written about frequent TCP disconnections and poor connectivity on unitymedia (DE, English version here), but I believe they are going farther.

The evidence
I had a strong suspicion from my regular use that unitymedia was filtering connections, but I needed a good way to prove it.

Since the most common use for a VPN is to get around region restrictions (honourable mention to YouTube DE and GEMA) or to download copyrighted content illegally, I thought torrenting Ubuntu 14.04 would be a good example use case.

I installed Transmission and configured it to require encrypted connections. This will ensure that any network connections to peers will be encrypted UDP. I should also note that IPv6 was disabled on the computer, so only IPv4 connections are possible.

So, for the first test, I downloaded the torrent for Ubuntu 14.04 LTS AMD64, and started downloading.

encrypted_udp_torrent_novpn

Everything is still working, good.

Now I paused the torrent and logged in to a paid OpenVPN service on UDP port 1194. To prove that the connection is working, I will run a ping test to Google’s public DNS. This is what happened next:

encrypted_udp_torrent_udpvpn

Okay, so we are still downloading, but much slower than before. Unitymedia would not be the first ISP in the history of the uncensored world to throttle VPN connections.

However, we cannot browse to websites. Chrome and Firefox just sit forever waiting for data from the remote server. To test my VPN connection, I tethered my phone to my PC and logged in to the VPN. Websites load perfectly.

But, what if we tried a TCP-based OpenVPN connection? Let’s connect to an OpenVPN endpoint using TCP on port 443. In the upper right xterm I have logged into my router and I am filtering for TCP RST packets on my upstream WLAN connection (to the unitymedia router). We can see that the ping is still running, although we have not started to download anything yet.

encrypted_udp_torrent_tcpvpn-working

I resume the torrent and all of a sudden I receive 2 TCP RST packets and the connection is dead.

encrypted_udp_torrent_tcpvpn-blocked

This is absolutely unacceptable. Under no circumstances should an ISP ever be inserting TCP RST packets into a user’s connections. Here is the PCAP file with the TCP RST packets that ended my connection.

ISPs inserting TCP RST packets to disrupt user connections is sadly not new. Comcast in the United States has been known to forge TCP RST packets for users who are using bittorrent, calling it “Network Management.” The EFF even compiled a report on Comcast’s shady behaviour. There is a Wikipedia article on the TCP reset attack if you want to know more about how it works.

An ISP is providing a service to paying customers, and at no point should they ever interfere or attack a customer’s connections. Sadly these days the terms of service (ToS) are usually in favour of the service provider, and not the customer.

I find it ironic that in Germany, which has spied on its citizens in the past, I cannot use such privacy enhancing technology as VPNs.

There are many legitimate uses for a VPN such as: encrypting your internet traffic from your ISP, anonymizing yourself to avoid higher prices in online shopping, or getting cheaper plane tickets for your holiday.

I have confirmed that this issue is not isolated to my Unitymedia connection. I have a friend living in another large German city, and their connection faces the same hostile behaviour from Unitymedia.

Unitymedia’s filtering is also not limited to commercial VPN services. My work requires I use a VPN connection to access internal services, and I frequently experience disconnections, dropped packets, extreme throttling, and corrupted packets while trying to work.

So, why am I writing this? I live in a free country, I can vote with my wallet and move to a different ISP. This is true, but if I did that, people who do not have the technical knowledge to diagnose connection problems would never know that Unitymedia is censoring their internet. Unitymedia would just be blasted for their DS-Lite implementation, and things would never improve.

In conclusion:

linus-torvalds-220612

Unitymedia is sending forged TCP RST packets to disrupt TCP VPN connections. They are throttling, and I suspect also filtering, UDP VPN connections to a severe extent.

thatwouldbegreat