Peter Cooper

Pipex Filtering HTTP Traffic In A Rather Weird Way

I’m just posting this as a record of what occurred and in case it comes in useful to anyone else Googling on the topic.

Yesterday, it appears my DSL / ADSL / broadband provider, Pipex, had some minor outages. Whereas others thought their broadband simply wasn’t working, I discovered otherwise. Everything worked except any HTTP requests on port 80 or 443 featuring a Host: header and that would ultimately return status code 200. I confirmed all of this with lots of playing with curl in verbose (-v) mode, letting me see all HTTP traffic going in and out under different conditions.

To put that into perspective, a request to a non-existing page, such as http://news.bbc.co.uk/nonsense worked fine. A request to a page that did a redirect (such as http://tinyurl.com/1ab) did the redirect fine, but then the final destination wouldn’t load (since it’d be status 200). An HTTP 1.0 request with no Host: header would work fine (though almost nothing supports this properly anymore). XBox Live worked fine (which is what I ended up playing on since the Web wouldn’t work!), POP3 worked fine, IMAP worked fine, SSH worked fine, pinging worked.. everything worked except HTTP requests on ports 80 and 443 that would usually return an HTTP 200 OK. It was like this between about 8 and 10pm on Wednesday, July 2, 2008.

Curiously, an HTTP request to Pipex’s own Web site initially appeared to work fine, but then hung like all the others after returning only about 2KB of HTML.

This all makes me think that Pipex (or someone in their chain of connections) is passively proxying HTTP requests, most likely for surveillance purposes (or possibly caching). Since requests resulting in 301 / 302 redirects and 404s were still getting through, they’re clearly interrupting the connection at some point. These stalled connections were hanging in FIN_WAIT_2 (according to netstat), demonstrating that the connection was effectively idle (to the point of timing out), and waiting for something to arrive.

Pretty much every ISP operates a proxying service without it being evidently clear to the end user. NTL were the worst “back in the day,” with their Inktomi proxies constantaly screwing up.

Interestingly (for me anyway,) one of the guys I currently work with used to work for NTL during those times, so I’ve now experienced it as a user and heard about it from a system admin. perspective too.