5

My local housing Internet provider just changed its policy and they seem to be blocking routers from working1.

My setup (which has been working for a year):

[ISP router (in the residence, out of my reach)] -- My DD-WRT router -- PC

-- : RJ45 cable connection

As of now, it stopped working. After some tests, here's what I found out:

  • Router-PC connection seems OK (I can access its web interface and via SSH)
  • Router-ISP connection seems OK (by SSH-ing to my router, I could ping 8.8.8.8/8.8.4.4)
  • PC-Router-ISP connection does not work (cannot even ping 8.8.8.8/8.8.4.4)

I'd like to understand if it's possible for an ISP to block connections this way, and if there's a way to avoid it2.

1 This change is apparently to prevent people from using more than one device at the same time. This is an arbitrary rule which has never been announced. They can only pull this off because they have a monopoly on my student residence.

2 I don't think this would be unauthorized, since I never signed any ToS or had to accept any EULA. The day I moved in, I plugged my router and it had been working ever since. I pay the rent, and my residence pays the ISP, hence the monopoly.

Details about my setup

I'm using DD-WRT on its standard Gateway configuration. It seems this is a one-to-many NAT, since this website says that:

To disable NAT and still have it route/firewall, you can change operating mode to 'Router' instead of 'Gateway' (located in Advanced Routing)

And this DD-WRT wiki page explains how to configure a one-to-one NAT, therefore my default configuration should be a one-to-many NAT.

Is this correct? If this is already the case, would my ISP be able to somehow detect if I'm using a direct connection or not? I thought that manually setting the TTL of the packets from their router to 1 would have that effect, but I'm not sure.

Edit: Maybe I'm misunderstanding it, but TTL could be the culprit. Here's the result of ping 8.8.8.8:

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=1 time=12.3 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=1 time=3.52 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=1 time=21.1 ms

Notice the TTL field is always 1.

However, I had never paid attention to that before. Could this be normal? Otherwise, could I tell DD-WRT to increase it?

7
  • What type of NAT do you have configured on the router (if you have at all)? One-to-one or One-to-many? With one-to-many NAT everything behind the router should not be visible to your provider since all source IP-addresses are changed to the router's public IP-address on fly. For provider it should look like only one device is connected.
    – VL-80
    Aug 27, 2015 at 19:30
  • I'll have to check it, since DD-WRT's NAT/QoS tab only lists port forwarding settings. After installing DD-WRT, I don't think I've ever had to change the default settings, so I believe there's no NAT configured, or maybe everything is already NATted by my router. If I should activate NAT, should I choose One-to-one or One-to-many?
    – anol
    Aug 27, 2015 at 19:51
  • 2
    Check it. With no NAT configured devices behind the router are not "hidden" from the outside world - I mean connections made from such devices will have the source address of their originating devices. If this is the case then your provider can spot it and block such connections. You should enable one-to-many NAT.
    – VL-80
    Aug 27, 2015 at 19:56
  • Pardon the ignorance, but I'd expect DD-WRT routing to already do one-to-many NAT by default, since it creates a subnet in which my PC has a 192.168.* IP, and I have to manually forward any ports to the devices in my LAN. I'll edit to add details about what I found
    – anol
    Aug 27, 2015 at 20:04
  • 1
    @anol, check this answer out. A packet with TTL 1 arriving to your router will stop there - will not be forwarded. And also this article. If your router allows you to change the TTL, than try to increase TTL of incoming packets. In this way packets should be able to reach your host behind the router. If it does not work - we will have to work something out based on the second article.
    – VL-80
    Aug 28, 2015 at 14:05

1 Answer 1

5

Turns out that it was indeed the TTL that was causing the issue! Here's an FAQ-style answer, hopefully more broadly useful for other people.

Why does my connection only work via direct cable, but not via a router? Is my router not working properly?

If your situation is like mine, the router was (and is) working just fine. The issue is that my ISP just implemented TTL throttling.

What is TTL throttling?

TTL throttling consists in setting the TTL (time-to-live) of IP packets to 1, in order to prevent the use of routers: all packets from the WAN (Internet) are dropped before reaching the PC (because their TTL becomes 0).

How can I detect TTL throttling?

When connected using direct cable (which should work normally), try pinging any server, preferably by IP to avoid DNS issues. Google's public DNS server is easy to remember, so I often do:

ping 8.8.8.8

The result will contain a field ttl (or TTL on Windows):

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=1 time=12.3 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=1 time=3.52 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=1 time=21.1 ms

In this example, the TTL is exactly 1. The chances of this happening in practice, without TTL throttling, are nearly zero. ttl=1 is the indicator that your TTL is being throttled.

How to circumvent TTL throttling?

You need to configure your router so that it will modify the TTL of the incoming packets, increasing it to a higher value (say, 64) so that packets will not be dropped before arriving at the devices connected to your router.

Unfortunately, specific details will depend on each router/firmware. I had DD-WRT installed in my router, so I used iptables rules to configure it.

After various attempts, I ended up succeeding in defining a rule that worked for me, but every firmware version may be different! You may have to try several combinations before finding one that works.

General tips about configuring DD-WRT iptables to cancel TTL throttling

  • If you can, use the SSH command line to connect to the router. It's faster and it gives you feedback about incorrect commands;
  • You probably will have to understand the iptables syntax in order to fix the command so that it'll work for you;
  • I still don't understand it enough, and I was tired of trying, so I just stuck with the first one that worked, although it most probably is not the best one.

Here are the commands that I added to my DD-WRT startup script:

iptables -v -t mangle -A OUTPUT -j TTL --ttl-set 60
iptables -v -t mangle -A PREROUTING -j TTL --ttl-set 63

They are almost surely wrong at some level, but the important parts are:

  • always use -v to obtain verbose output; incorrect commmands will be indicated;
  • avoid using -n (for numerical, i.e. IP output); despite being mentioned in DD-WRT's Iptables page, this option does not seem to exist in my DD-WRT version, resulting in a silent error. I only noticed it by echoing $? after the command, which resulted in 255 instead of 0. Removing this option allowed me to see the error messages;
  • for quick testing without a working Internet connection on the PC, you can let a ping command running on the PC on a console, while you try the iptables commands on another console. By default, my router was replying with ttl=64, but when I got a rule that worked, I could instantly see ping returning with the new value (hence why I did not use 64 in my example) when using the OUTPUT chain (otherwise, it is not necessary for the actual Internet connection);
  • some people mention chain PREROUTING, others mention INPUT. I'm not sure of the difference, but the PREROUTING seems to have worked better for me.

Unfortunately, this is still not ideal: every hour or so, my connection seems to get reset, so I have to manually update the iptables rule.

Note: I barely know anything about iptables, so any suggestions for better rules are welcome (I will test and update them accordingly).

Windows/Mac Internet sharing

If you are using a Windows/Mac computer as router (e.g. using your PC/laptop to share your Internet connection with other devices), software such as Connectify (since its version 7.1, according to their website) also enables bypassing TTL throttling.

Connectify calls this setting avoid Hotel/NAT restrictions. It is active by default, which would explain why there are not so many people complaining about TTL throttling on the Internet: Windows users end up mostly using Connectify, without asking why it works. This would however explain why Windows' standard Internet connection sharing might not work out of the box.

And on a final note...

Should I feel bad about avoiding TTL throttling?

Probably not, especially if your ISP, like mine, (1) already does bandwidth throttling, (2) introduces TTL throttling without ever announcing it, and (3) is clearly only interested in cheating its users, instead of improving the service. Removing a standard feature artificially and by "cheating" (faking TTL is cheating), only to charge twice as much to put it back, is a very scummy move.

0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .