From owner-freebsd-pf@FreeBSD.ORG Tue Jul 24 17:12:37 2012 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 088621065673 for ; Tue, 24 Jul 2012 17:12:37 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (106-30.3-213.fix.bluewin.ch [213.3.30.106]) by mx1.freebsd.org (Postfix) with ESMTP id 681E48FC08 for ; Tue, 24 Jul 2012 17:12:35 +0000 (UTC) Received: from insomnia.benzedrine.cx (localhost.benzedrine.cx [127.0.0.1]) by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id q6OHCPqW008280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Jul 2012 19:12:26 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id q6OHCPp7028980; Tue, 24 Jul 2012 19:12:25 +0200 (MEST) Date: Tue, 24 Jul 2012 19:12:25 +0200 From: Daniel Hartmeier To: Jason Mattax Message-ID: <20120724171225.GA27107@insomnia.benzedrine.cx> References: <20120723100521.GC32530@insomnia.benzedrine.cx> <500E1202.20108@storytotell.org> <20120724070700.GF32530@insomnia.benzedrine.cx> <500EB432.6050803@storytotell.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <500EB432.6050803@storytotell.org> User-Agent: Mutt/1.5.12-2006-07-14 Cc: jmattax@clanspum.net, freebsd-pf@freebsd.org Subject: Re: PF suddenly malfunctioned X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 17:12:37 -0000 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