From owner-freebsd-pf@FreeBSD.ORG Mon Jul 23 09:12:57 2012 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAFF2106564A for ; Mon, 23 Jul 2012 09:12:57 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 55D9A8FC0C for ; Mon, 23 Jul 2012 09:12:57 +0000 (UTC) Received: by lbon10 with SMTP id n10so9608981lbo.13 for ; Mon, 23 Jul 2012 02:12:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=SAd99QfhXzanIr6EU08B6b9S+Vc0lhKgiEDSoYUEENI=; b=mDAg29S/WQcLYqQ0e3AByZDJ+4yKotmT9Qe6eT75uHeLAoYr90uSjtBN+F04IQvPxV AEyKIKr3zQ2ALMsTFc5Au3FgB75u1dl4tnJ51WGHZ2rA8iQWb2l9HFY3qElpz4nRpiRd 4JeECFJmRcEx4caa/PsnvbAlFI4jOngzDXiTgiEMuSJ/pUVwODbgLU4yO77lcWXfOV7r kJh6OzuohbPiF4zQnvGHkXPP48Y4i3Ju3rkTCWLaBp/p4zZC7cR1jHijsGGDJ6GSpc6s JRy5qcRhPeoVT5jjQ5Rdpiv528Yb4YRCkwxc3LW+z2aHfRkAt4bVoXNK0ksMwL3LfdJ0 4GEQ== Received: by 10.152.46.232 with SMTP id y8mr15995107lam.18.1343034776292; Mon, 23 Jul 2012 02:12:56 -0700 (PDT) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id fy10sm12852170lab.0.2012.07.23.02.12.54 (version=SSLv3 cipher=OTHER); Mon, 23 Jul 2012 02:12:55 -0700 (PDT) Message-ID: <500D1595.4010405@my.gd> Date: Mon, 23 Jul 2012 11:12:53 +0200 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Jason Mattax References: <2B5A7CC5-0950-47E9-928F-D5909238052C@my.gd> <500CE1B2.5040303@storytotell.org> In-Reply-To: <500CE1B2.5040303@storytotell.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQngpyU4tU+8p1x0c4IWsSRZXTfbOzwlwpDZLq/WOZpB15kDxqK82TH64YLVzSccjme+ZEZs Cc: 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: Mon, 23 Jul 2012 09:12:58 -0000 On 7/23/12 7:31 AM, Jason Mattax wrote: > > > On 07/22/2012 07:30 PM, Damien Fleuriot wrote: >> >> On 23 Jul 2012, at 01:49, jmattax@clanspum.net wrote: >> >>> A few weeks ago (I've been trying to debug it myself since then) my pf >>> firewall stopped working fully correctly. The symptom is that I can >>> no longer >>> access a variety of websites when I'm behind the firewall. I have >>> verified >>> that I can access all of the affected websites from outside my >>> firewall. I >>> have since stripped down my firewall (and general home server) so >>> that it is >>> no longer running named, sshguard or any useful firewalling rules in an >>> attempt to figure out was broken but have been unable to do so. >>> >>> Attached are my current /etc/pf.conf and /etc/rc.conf, to ensure that >>> these >>> are the configurations being used as of my last test I restarted the >>> system >>> and am still getting the same behavior. This behavior started >>> sometime around >>> a storm at my house, but since the firewall can see the websites that >>> the >>> computers behind it can't I don't believe the hardware is an issue. >>> >>> Also, some websites (like anything google hosts) are just fine. >>> >>> The also, so people can see what my kernel thinks I've attach the >>> output of a >>> couple of commands below >>> >>> [root@ ~]# pfctl -s rules >>> No ALTQ support in kernel >>> ALTQ related functions disabled >>> pass in quick all flags S/SA keep state >>> pass out quick all flags S/SA keep state >>> [root@ ~]# pfctl -s nat >>> No ALTQ support in kernel >>> ALTQ related functions disabled >>> nat on xl0 inet from 10.11.10.0/24 to any -> 192.168.0.200 >>> [root@stilgar ~]# ifconfig >>> re0: flags=8843 metric 0 mtu >>> 1500 >>> >>> options=389b >>> >>> ether 90:e6:ba:60:9a:33 >>> inet 10.11.10.1 netmask 0xffffff00 broadcast 10.11.10.255 >>> media: Ethernet autoselect (100baseTX ) >>> status: active >>> xl0: flags=8843 metric 0 mtu >>> 1500 >>> options=82009 >>> ether 00:01:03:d1:fa:90 >>> inet 192.168.0.200 netmask 0xffffff00 broadcast 192.168.0.255 >>> media: Ethernet autoselect (100baseTX >>> ) >>> status: active >>> plip0: flags=8810 metric 0 mtu 1500 >>> ipfw0: flags=8801 metric 0 mtu 65536 >>> lo0: flags=8049 metric 0 mtu 16384 >>> options=3 >>> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 >>> inet6 ::1 prefixlen 128 >>> inet 127.0.0.1 netmask 0xff000000 >>> nd6 options=3 >>> pflog0: flags=141 metric 0 mtu 33152 >>> >>> I would be very appreciative of any suggestions anyone can offer. >>> >>> Jason Mattax >>> >> >> 1/ OS version ? We can't tell from the current info >> > [jmattax@ ~]$ uname -a > FreeBSD hostname 8.2-RELEASE-p9 FreeBSD 8.2-RELEASE-p9 #0: Mon Jun 11 > 23:00:11 UTC 2012 > root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 > > based on that I could easily upgrade to 8.3, or possibly 9.0 tomorrow if > I have the inclination. > I can recommend 8.3, we're using it widely in production. >> 2/ When the problem appears. Have you tried disabling PF ? (pfctl -d) >> Does it help ? >> > Since I can consistently reproduce the problem with en.wikipedia.org I > have a good way to test. When I run pfctl -d on the firewall it looks > like no traffic is being forwarded, including DNS so I eventually get a > notice that the web page timed out because I typed the address wrong. > That is as opposed to the web browser saying waiting for > en.wikipedia.org (and if I recall correctly occasionally getting the > redirect to en.wikipedia.org/wiki/Main_Page.) I just tested and got > stuck at the waiting for en.wikipedia.org for a couple of minutes before > I called it good enough to report here. > Keep in mind that after disabling PF you don't get NAT anymore from your workstations through the firewall. So any test you run while PF is disabled has to be run from the PF box itself. >> 3/ The websites wouldn't be using connection recycling per chance ? >> (linux) >> We've had a lot of problems with Linux enabled hosts using recycling, >> having them turn it off solved the problems. >> There was not a thing we found on our side to fix it. >> Disabling scrubbing wouldn't help either. > > To be clear wikipedia was working with a full firewall configuration, so > although I believe they are hosted on linux I would hope someone else > would also see this problem. I know there are other websites that also > became broken around the same time, but because they are largely > advertisement hosting websites I don't know their names off hand and > have been bypassing the firewall for the moment. > > Thanks > Jason