Date: Tue, 15 Dec 2009 14:14:08 -0500 From: Linda Messerschmidt <linda.messerschmidt@gmail.com> To: Peter Maxwell <peter@allicient.co.uk> Cc: freebsd-pf@freebsd.org Subject: Re: Lots of weird PF behavior on 7.2-STABLE Message-ID: <237c27100912151114w6912dd63l80523d02831b2588@mail.gmail.com> In-Reply-To: <7731938b0912150808y5cfa7cbs3bb31b80f222159c@mail.gmail.com> References: <237c27100912142221k6cf62b7ay97c8ae20bd0e7eb2@mail.gmail.com> <7731938b0912150808y5cfa7cbs3bb31b80f222159c@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 15, 2009 at 11:08 AM, Peter Maxwell <peter@allicient.co.uk> wrote: > I'm pretty sure you can run tcpdump against a packet capture from the > pflog interface on the pf box; that will include fields like > block/pass and rule number for each packet filtered. I have done that with "log" on all block rules. The packets shown as missing are *not* present in the dump when I do, so as far as I can tell they are not being dropped by a filter rule. Which makes sense, since none of the few block rules we have would touch packets in the middle of an established connection that was permitted. For comparison, endless streams of packets from those DNS guys we block *are* present in the tcpdump output, exactly as you describe, so I know pflog is working. So it really seems like something wrong in the internals of pf. I just don't know how to pursue it further. > However one thing that I would strongly suggest is using proper packet > filter design: either decide upon a default deny then pass what you > want, or decide on a default pass and only deny what is bad. We are doing the latter; default pass and denying only what is bad. This isn't even really a firewall, it's for load balancing web connections. We just threw a couple of block rules in there because it was a good place to stop a particular attack. There are other "default deny" firewalls on other machines that handle all the traffic that isn't getting diverted by the load balance rule. > If you're having to use the "quick" keyword, you've probably* > done something wrong. Since we are using load balancing, the "pass" rule that wouldn't pass all the traffic we've just gone to the trouble to block would be outrageously complex. Hence, quick. If a case can be made that the use of "quick" is causing our packets to disappear, we'd probably be willing to tackle trying to restructure the rules. Thanks!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?237c27100912151114w6912dd63l80523d02831b2588>