20 comments

[ 3.1 ms ] story [ 52.2 ms ] thread
Is this assumption true of all mobile network providers? If yes, wouldn't the network provider notice the huge increase in UDP traffic from your phone and start blocking it?

"How it works

By default mobile provider blocks any packet but UDP packet, unless you pay for the service. My method consists in sending TCP/UDP/ICMP frames as payload of an UDP packet to a known host (your server). Your server reinjects these frames to Internet."

It definitely won't be true for all mobile operators. I'd be a bit surprised if it's even true of the original one at this time. The software seems to be from two years ago, and this would have been a stunningly generous policy by the standards of that time period -- the description says that they were only blocking TCP port 80! (Already 10 years ago the main hole open in captive terminals was properly formatted DNS requests/responses, so you'll find a lot of ip-over-dns tunneling projects from around that time).
Yes, this will not work at all in countries/ISP with VoIP blockage. You might check mizutech voip tunnel (http://www.mizu-voip.com/Software/VoIPTunnel.aspx) using more serious encryption and obfuscation and still in need for constant improvements because of "deep packet inspection" used nowadays by many ISP's. Some provider blocks all UDP, some allows only HTTP on port 80 and there are ISP's with even more restrictions. For example in Iran the ISP just drops all stream with both up and download, thus making all these kind of simple hacks unusable. (To bypass such kind of blockage you need to split your traffic to multiple up/download links via multiple server addresses).
Reminds me of Iodine (IP over DNS): http://code.kryo.se/iodine/

Of course, it only works if DNS resolution is allowed without auth, which can vary a lot.

iodine is awesome, but is usually very slow, in real-life tests I've rarely gotten anywhere close to the benchmarks cited in the README.

Nonetheless, it's an awesome tool to help you get that beachhead and upgrade your connection from there.

iodine will detect if the server is directly reachable and in that case send full frames in both directions, just like this application or a normal vpn.
How is this different from a VPN over UDP, like OpenVPN or Cisco Anyconnect?
> It's useful to avoid Internet restrictions

It's used to bypass DPI where known VPN softwares are already filtered.

How many providers have DPI filtering for select apps on unauthenticated connections? Exactly zero.
I don't know. But where I'm working, I have to register my company's VPN traffic (DST IP addr) to pass their (state owned company) filter. Edit: Not in China.
Exactly, that was my first thought. I have an OpenVPN endpoint on different ports over UDP and TCP available.

My experience is, that UDP is also blocked like TCP. The only possible work around is then IP over DNS, which works but with very very limited bandwidth.

On cellular networks, my experience is that everything on port 53 is hijacked and shipped off to a telco DNS server though.
> The only possible work around is then IP over DNS

What about tunnel over HTTP? That can be much better obfuscated. Tunnel over DNS can be easily filtered out by just checking for the traffic amount (for example to block VoIP the ISP should just degrade DNS if traffic amount is above a treshold for a user)

(comment deleted)
It is easier to hack and make small changes i presume.
In some countries all VPN is blocked (so the ISP will simple block the stream if standard VPN headers are detected).

These kind of tunnels allows custom, obfuscated protocols.

It turns out this is kind of already in the Linux Kernel. See here: https://lwn.net/Articles/614348/

You can tunnel TCP / IP / GRE, reasonably even Ethernet itself over UDP. This is actually really interesting for cases where you want layer 2 bridging over the internet without all the complexity and overhead of a VPN.

Wouldn't work directly here, as "ip fou add" reserves a local port, while in OP's case it's a reserved remote port. And reserving local port 53 in case of 53<->53 packets would kill dns resolution.

With an extra iptables rule should work though:

  iptables -t nat -A PREROUTING -s my.server -p udp --sport 53 -d DNAT --to 127.0.0.1:5555
  ip fou add port 5555 ipproto 4
Agreed. The same is true for VXLAN which is also in the Kernel and also runs over UDP.
(comment deleted)