# [SOLVED]Here's a challenge... can't reach britishairways.com

## penetrode

That's right.

Every other site I have ever tried to reach on this machine, I can reach. Never even had the hint of a problem. But connect attempts to www.britishairways.com always fail.

I have had this problem on a different Gentoo box before. Other machines (sadly, Windows machines) on the same network were able to reach the site. And I have checked -- the site is up for everybody else I've asked to test it for me.

I have done the obvious things, like restart my machine and restart the router. No luck. I have tried it with links and telnet ('telnet 163.166.156.201 80').  Failed also.

I thought it might be that my packets were too large, so I tried various MTU sizes (1492, 1460, 1440, 1300, 576). None of those has worked.

I tried turning off ECN (Explicit Congestion Notification). Still nothing.

Here's some traceroute output that you might find illuminating:

```

traceroute to 163.166.156.201 (163.166.156.201), 30 hops max, 60 byte packets 

 1  fritz.fonwlan.box (192.168.178.1)  5.585 ms  6.325 ms  6.993 ms

 2  dslb-084-058-000-001.pools.arcor-ip.net (84.58.0.1)  19.682 ms  20.413 ms  22.484 ms

 3  145.254.0.73 (145.254.0.73)  24.596 ms  25.343 ms  26.399 ms

 4  92.79.213.130 (92.79.213.130)  28.098 ms  28.843 ms  30.811 ms

 5  fkft-ic-1.inet.ntl.com (80.81.192.5)  33.398 ms  36.728 ms  38.121 ms

 6  nth-bb-a-as2-0.network.virginmedia.net (62.253.185.82)  59.458 ms  32.611 ms  33.742 ms

 7  nth-bb-b-ae0-0.network.virginmedia.net (62.253.185.118)  39.703 ms  37.187 ms  37.848 ms

 8  * * *

 9  * * *

10  haye-lam-1-tenge71.network.virginmedia.net (62.30.244.50)  34.557 ms  31.003 ms  32.682 ms

11  82.44.128.114 (82.44.128.114)  38.930 ms  35.869 ms  37.811 ms

12  163.166.150.88 (163.166.150.88)  42.066 ms  38.014 ms  42.072 ms

13  ba.com (163.166.156.201)  8535.801 ms  8323.657 ms  8426.410 ms

```

Fascinating, that last hop, no? That's the target server. It only shows up because I set the wait time to 10 seconds. It takes eons (or about 8 seconds in this case), but it does eventually respond. I have seen response times anywhere from 4.5 seconds, to 9.5 seconds.

When I do a Wireshark packet capture during an http connect attempt, I can see three SYN packets, and then finally a RST ACK from the BA server, followed by nothing. Very strange.

I suspect the router/firewall in front of BA's webservers is doing something that doesn't agree with my packets. I discovered that name lookup requests to BA's name servers also fail with a timeout, and they are on the same /20 subnet.

In a test with a colleague, I set up a NAT on the other side of the planet. Sending my traffic through that NAT (using an /etc/hosts entry), it worked like a charm. Along with the fact that the target subnet is clearly reachable from my location, this suggests that something about how my packets are assembled is the problem, but I would be happy to be proven wrong. Still, "it's probably a routing issue" is probably not the answer.

A final note -- I am not running iptables, so that isn't the problem either. And there is nothing funky about my kernel (though it might be yet be a kernel config issue). Again: every single other website or other service I have tried to use works.

Having tried the obvious things, I wouldn't know what to change. Help!Last edited by penetrode on Sat Feb 13, 2010 11:33 am; edited 1 time in total

----------

## b0nafide

I can connect to www.ba.com on two gentoo systems and one windows virtual machine. 

However, I cannot ping www.ba.com, there is no response at all. 

Therefore my traceroute output (even with -w 10) is different: 

```
# traceroute 163.166.156.201 -w 10 

traceroute to 163.166.156.201 (163.166.156.201), 30 hops max, 40 byte packets

 ... 

12  82.44.128.114 (82.44.128.114)  183.969 ms  185.405 ms  184.903 ms

13  163.166.150.88 (163.166.150.88)  183.127 ms  192.981 ms  192.401 ms

14  * * *

15  * * *

 ... 

30  * * *
```

Not only are you not able to connect to www.ba.com but it also appears you are one of the lucky few who can ping it, even if the response time is terrible.

----------

## KayZee

What web browser?  Have you tried different web browsers?

Can you reach www.ba.com?

Have you tried a static entry in /etc/hosts for www.britishairways.com pointing to 163.166.156.201?

----------

## Jaglover

I believe not responding to ICMP does not mean much, it may be the choice in firewall configuration. Responds fine to tcptrace.

```
tcptraceroute 163.166.156.201

Selected device eth0, address 192.168.2.4, port 49298 for outgoing packets

Tracing the path to 163.166.156.201 on TCP port 80 (http), 30 hops max

 1  192.168.2.254  0.283 ms  0.309 ms  0.170 ms

 2  10.128.40.1  16.046 ms  16.127 ms  17.920 ms

 3  24.248.104.2  14.471 ms  17.355 ms  14.706 ms

 4  ip24-248-104-178.br.br.cox.net (24.248.104.178)  13.860 ms  14.667 ms  14.670 ms

 5  ashbbbrj02-ae0.0.r2.as.cox.net (68.1.0.221)  61.785 ms  60.745 ms  60.438 ms

 6  gfd-bb-b-as0-0.network.virginmedia.net (62.253.185.77)  147.883 ms  134.786 ms  134.117 ms

 7  bre-bb-a-as3-0.network.virginmedia.net (212.43.163.106)  139.255 ms  163.178 ms  135.950 ms

 8  osr01haye-pc200.network.virginmedia.net (212.43.163.118)  136.635 ms  135.696 ms  137.194 ms

 9  haye-lam-1-tenge71.network.virginmedia.net (62.30.244.50)  140.223 ms  139.666 ms  141.601 ms

10  82.44.128.114  144.066 ms  140.196 ms  141.259 ms

11  163.166.150.88  139.314 ms  136.281 ms  135.465 ms

12  163.166.157.18  136.619 ms  136.461 ms  137.463 ms

13  ba.com (163.166.156.201) [open]  140.670 ms  136.547 ms *

```

----------

## penetrode

Jaglover is right... my traceroute was invoked so:

traceroute -Tp 80 -w 10 www.britishairways.com

Essentially the same thing as tcptraceroute. Try it that way, I think you'll find it works. Nowadays, ICMP has become essentially useless. Too many misguided administrators think that turning it off makes them more secure.

Be that as it may, it doesn't get me any closer to a solution.

KayZee: It is not a DNS problem. The address resolves just fine (as does ba.com). It is not browser dependent, either. I have tried Firefox, Konqueror, links, and (as I mentioned above) even telnet. The connection is, after a long delay, unceremoniously dropped. Remember the packet capture? SYN, SYN, SYN followed by RST ACK. What is that all about?

A night has passed, and the problem is still there. So this is definitely something on my end, since apparently everybody else can reach it without trouble. The fact that two of my Gentoo machines have had this issue on two completely different networks on two different continents using two entirely different routers with different software tells me that it has to have something to do with the way I am configuring my machine.

But as I said... what? I have no idea...

----------

## Jaglover

Did you try and eliminate router. I know you said problem occurred behind different routers. Just to make sure router is not the culprit.

----------

## penetrode

 *Jaglover wrote:*   

> Did you try and eliminate router. I know you said problem occurred behind different routers. Just to make sure router is not the culprit.

 

Unfortunately, there's no easy way for me to do that. My roommate has the router and connection in his room, it's PPPoE, and I have none of the access details...

But yes, this problem occurred behind two totally different devices (one was running a current version of OpenBSD!), so it seems extraordinarily unlikely that that would be the cause.

When my other roommate gets home this evening, I can ask her to see if she can reach it from her Windows machine. I am willing to bet money that it will work for her.

----------

## penetrode

Are there any sysctl settings I could try that might fix this?

Maybe it's my kernel configuration?

----------

## Jaglover

Kernel would be the next, put the conf into pastebin.

Can you get ba.com with any LiveCD?

----------

## penetrode

Unbelievable: It turned out to be network dependent. I am now in a different location, and it works.

A colleague helped narrow down the cause: the IP block I was on is on a few dynamic IP blacklists; one in particular includes "dynamic address blocks that have been the source of spam" and other nasty things.

Filtering would definitely explain the "SYN SYN SYN RST ACK" phenomenon, and the incredibly long response times.

Having said that... this is a Vodafone address block. If BA is filtering this aggressively, they are denying access to a whole lot of people.

Anyway, it is a relief to know that it is not, ultimately, a Gentoo problem. Thanks for the patient help!

----------

