Lots of weird PF behavior on 7.2-STABLE

Linda Messerschmidt linda.messerschmidt at gmail.com
Tue Dec 15 11:14:10 PST 2009


On Tue, Dec 15, 2009 at 11:08 AM, Peter Maxwell <peter at 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!


More information about the freebsd-pf mailing list