Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 24 Jul 2012 19:12:25 +0200
From:      Daniel Hartmeier <daniel@benzedrine.cx>
To:        Jason Mattax <jmattax@storytotell.org>
Cc:        jmattax@clanspum.net, freebsd-pf@freebsd.org
Subject:   Re: PF suddenly malfunctioned
Message-ID:  <20120724171225.GA27107@insomnia.benzedrine.cx>
In-Reply-To: <500EB432.6050803@storytotell.org>
References:  <effb611b289f2b14d345c1cd63c9828a.squirrel@mail.clanspum.net> <20120723100521.GC32530@insomnia.benzedrine.cx> <500E1202.20108@storytotell.org> <20120724070700.GF32530@insomnia.benzedrine.cx> <500EB432.6050803@storytotell.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jul 24, 2012 at 08:41:54AM -0600, Jason Mattax wrote:

> The other thing I did was I accessed the wikipedia server at 
> 208.80.154.225 on the firewall. I did this so that I could do the nc 
> command on the firewall, the output of the tcpdump of which is attached 
> as xl0_tcpdump_nc and seems to have the same behavior as the nc behind 
> the firewall. Then I could run links en.wikipedia.org/wiki/Main_Page 
> (which works about half the time) and capture the tcpdump of that into 
> the attached xl0_tcpd_links so that people here could look at those 
> outputs in case they reveal something useful. In this case the links 
> worked, in the cases where it doesn't I get a message along the bottom 
> that reads "Received 0 B of 57 kB, avg 0 B/s, cur 0 B/s"

This begins to look like the problem is with the upstream NAT device
(which NATs source 192.168.0.200 again, right?)

So, the simple nc invokation reliably returns an empty HTTP response, no
matter if you run it on a client or on the firewall itself?

But if you run links, it sometimes works?

One difference is that links sends a longer HTTP GET request
(User-Agent: and Encoding: headers and such).

If the upstream router does HTTP inspection, it might be buggy (since
the thunderstorm? :) and react to different HTTP headers. Or it might
run an (broken) antivirus patterns on the HTTP result? Can you disable
any layer 7 inspection?

I'd tcpdump with -s 1600 -X to capture a working links connection. Then
extract the exact HTTP GET request from the hex dump. Then try to send
that with printf | nc. That should work equally well. If so, remove
headers until you hit the bug again.

Or just replace the upstream device (router, ISP modem?) and see if it
goes away.

The more far-fetched theories would be that wikipedia has some DOS
prevention or scraping protection going on that you somehow trigger.

Do you have a simpler server that reproduces the problem reliably,
possibly one that you have control over yourself, to tcpdump there?

Daniel



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120724171225.GA27107>