# Punching through The Great Firewall of T-Mobile

T-Mobile UK are moving towards a mobile network which works (technically) in a
very similar manner to the [Great Firewall of
China](https://www.wikipedia.org/wiki/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 <abbr title="Pay As You Go">PAYG</abbr> 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](https://www.wikipedia.org/wiki/Secure_Shell) and
[IMAP](https://www.wikipedia.org/wiki/Internet_Message_Access_Protocol) 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](https://www.tcpdump.org) 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](http://support.t-mobile.co.uk/discussions/index?page=forums&topic=80101915a8144e01337e648aca002435)
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](https://www.openvpn.net/)
to my [Linode.com](https://www.linode.com/) <abbr title="Virtual Private
Server">VPS</abbr>. 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:

```bash
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:

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

On the OpenVPN client:

```bash
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](#comment3205), the block on port 587 has now been
removed. The rest of the blocks are still in place though.