Cricket wireless appear to be blocking access to 5.x.x.x


#1

I received a report from a user using cricket wireless who was unable to access raspbian.org services (which are hosted on 5.153.225.206 and 5.153.225.207

I have checked they can reach a non 5.x.x.x bytemark IP so they appear to be blocking access to that IP range. I am guessing this is because until recently 5.x.x.x was regarded as a bogon and was widely abused by VPN software.

Has anyone else here encountered similar problems? does anyone have any advice for how to approach such ISPs in a way that gives the greatest chance of getting the block removed?


#2

Hi Peter,

Sadly this is common, but not usually for the reason of improper filtering. Often enough, it’s related to a broken netmask on a host (or router) that would break the IP routing for anything within 5.0.0.0/8, i.e. someone was assigned 5.6.7.8/29 and added 5.6.7.8/8 to a local LAN.

A bogon would be unallocated or reserved space, where-as I can assure you that we – and many other RIPE ISPs – are using a legitimate /21 from within 5.0.0.0/8, and that blocking 5/8 completely would be an endless stream of user complaints from anyone that used such a filter. Certainly it’s the first time I’ve heard of 5.0.0.0/8 being filtered with any reach.

Do you happen to have a traceroute (or better, mtr output) from the user in question? Getting them in-touch with their ISP support is the first step. Of course if this turns-out to be ISP-wide filtering (and we can prove that it’s a larger problem within the ISP’s network) and not just a broken host computer at the customer’s site, there’s a possibility that we can contact the ISP at a peering/NOC level to resolve this.

Tom


#3

The original thread is at http://www.raspberrypi.org/phpBB3/viewtopic.php?f=63&t=61065 . This is a cellular connection and appears to be using “carrier grade NAT”.

traceroute 5.153.225.207

1 192.168.xx.x 20.007 ms 23.852 ms 28.059 ms
2 10.135.115.74 162.743 ms 166.740 ms 170.738 ms
3 ***
4 ***

By contrast a traceroute to a non 5.x.x.x bytemark IP looks like

1 3 ms 1 ms 3 ms 192.168.43.1
2 182 ms 162 ms 132 ms 10.135.115.74
3 130 ms 145 ms 96 ms 10.135.115.74
4 193 ms 155 ms 164 ms 10.135.115.49
5 131 ms 128 ms 153 ms 10.132.50.53
6 123 ms 122 ms 168 ms 172.16.3.251
7 177 ms 146 ms 152 ms xe-7-0-0.edge4.Chicago3.Level3.net [4.53.98.29]

8 240 ms 405 ms 237 ms vlan51.ebr1.Chicago2.Level3.net [4.69.138.158]
9 259 ms 243 ms 219 ms ae-6-6.ebr1.Chicago1.Level3.net [4.69.140.189]
10 254 ms 239 ms 251 ms ae-2-2.ebr2.NewYork2.Level3.net [4.69.132.66]
11 225 ms 210 ms 258 ms ae-1-100.ebr1.NewYork2.Level3.net [4.69.135.253]
12 244 ms 221 ms 236 ms 4.69.201.45
13 259 ms 233 ms 241 ms ae-41-41.ebr2.London1.Level3.net [4.69.137.65]
14 256 ms 245 ms 249 ms vlan102.ebr1.London1.Level3.net [4.69.143.89]
15 566 ms 345 ms 445 ms ae-4-4.car1.Manchesteruk1.Level3.net [4.69.133.1
01]
16 362 ms 207 ms 194 ms te3-5.cr2.man.bytemark.co.uk [195.50.119.78]
17 315 ms 243 ms 324 ms te1-5.cs1.reynolds.man.bytemark.co.uk [91.223.58
.79]
18 370 ms 316 ms 233 ms yates.bytemark.co.uk [89.16.188.27]
19 284 ms 250 ms 272 ms p10link.net [80.68.89.68]

Given the large step in latency it seems pretty clear to me that 10.135.115.74 is part of the ISP network, not a device belonging to the end user.