Grepular

Punching through The Great Firewall of T-Mobile

Written 13 years ago by Mike Cardwell

T-Mobile UK are moving towards a mobile network which works (technically) in a very similar manner to the Great Firewall of China. I’ve been using them for mobile Internet access for over a year now, and recently received a second SIM card. When using this new SIM card for Internet access, I’ve experienced some very odd network traffic.

Both SIM cards are PAYG and both have had their default content block removed. I do not know why they behave differently, but it seems like T-Mobile may be in the middle of rolling out some related changes; There is a quote regarding this from a T-Mobile rep, that I will come to later.

What works?

I have no problems browsing the web. Simple web browsing seems to work fine. SSH and IMAP also seem to work fine. There are almost certainly other approved services that work, which I haven’t tested yet.

What doesn’t work?

I run my own Linux server, and self-host several services. I use SSL whenever possible. If I connect to my mail submission service with immediate encryption on port 465, T-Mobile instantly sends a spoofed RST TCP packet to both my server and my client in order to disrupt/disconnect the connection. I ran tcpdump on both ends of the connection to verify that this was happening. They also do the same for mail submission port 587. This time, they let you connect, but as soon as you send a STARTTLS command, the RST packets appear, and the connection drops. This isn’t just for my mail server, I experienced the same problems using smtp.gmail.com as well.

About six weeks ago, somebody else pointed out the same problem on the T-Mobile forums. A further two people and myself have commented on that thread due to discovering this issue. One of the commenters stated:

“I finally got to the bottom of this. I was contacted by T-Mobile technical support today and was told that they are now actively looking for and blocking any TLS-secured SMTP sessions. So, it is a deliberate policy after all, despite what the support staff have been saying on here, twitter and on 150. They told me it is something they have been rolling out over the last three months - which explains why it was intermittent and dependent on IP address and APN to begin with.”

It seems the only server they want you to use for sending email when connected to their network is smtp.t-email.co.uk.

Is it just SMTP? What else doesn’t work?

I route all of my Internet traffic over an OpenVPN to my Linode.com VPS. This has always worked fine with my original SIM. With the new SIM, no matter which port I configure OpenVPN on, the RST packets appear. IMAP over SSL on port 993 works fine, but if I switch that off and configure OpenVPN to listen on port 993, it is blocked. So the blocks aren’t even port based. They’ve got some really low level deep packet inspection technology going on here. The Great Firewall of China uses the exact same technique of sending RST packets to disrupt connections.

Punching a hole through

I already stated that SSH works in the “What works?” section. For how long, is anyone’s guess. For limited applications, you can use this hole to tunnel traffic over an SSH connection to your server. If you run the following command, it will spawn a socks service on port 1080 on your local machine, which you can point your various client applications at to tunnel them over SSH:

ssh -D 1080 your.server.example.com

I didn’t want to tunnel OpenVPN over SSH though as it would have created too much latency to be tunnelling over a tunnel over 3G. Luckily, because I control both ends of the VPN, and both hosts are running Linux, I can simply configure the firewall to silently drop RST packets using the following commands: On the OpenVPN server:

iptables -A INPUT -p tcp -d vpn.ip.address --dport 1194 --tcp-flags RST RST -j DROP

On the OpenVPN client:

iptables -A INPUT -p tcp -s vpn.ip.address --sport 1194 --tcp-flags RST RST -j DROP

The same technique works to bypass the Great Firewall of China. After running these iptables commands, the VPN comes up fine. All traffic is routed over it so that T-Mobile can’t interfere or inspect anything else. God only knows what else they’re doing to their customers traffic.

Most people don’t run their own server. If you don’t, then you’re pretty screwed. Your only real options are to leave T-Mobile, or to learn to live with the restrictions. If you have a rooted Android phone, you can run iptables commands on it, so can drop the RST packets. However, you will still need the person who runs the server that you’re trying to connect to, to do the same at their end.

UPDATE: Thanks to dpg, the block on port 587 has now been removed. The rest of the blocks are still in place though.

Want to leave a tip?BitcoinMoneroZcashPaypalYou can follow this Blog using RSS or Mastodon. To read more, visit my blog index.