On Mon, Dec 26, 2005 at 05:28:04PM -0500, Forrest Aldrich wrote:
> # pfctl -sr
> scrub all no-df reassemble tcp fragment reassemble
> scrub in all fragment reassemble
> scrub out all random-id fragment reassemble
> block drop in quick on ! fxp0 inet from 24.147.44.0/22 to any
> block drop in quick inet from 24.147.44.26 to any
> block drop log all
> block drop in quick on fxp0 from <abuse> to any
There are exactly three reasons why a rule is not becoming the last
matching rule:
1) an earlier rule is matching and using quick, so ruleset evaluation
never gets to the rule in question
2) the rule in question simply doesn't match the packet at all
3) the rule does match, but is not using quick, and a subsequent
rule also matches
In your case, 1) is irrelevant, because all earlier rules are also
blocking. 3) is can be ruled out because your rule does use quick.
Hence[1], however improbably it seems, 2) must be the explanation.
How can the rule
block drop in quick on fxp0 from <abuse> to any
possibly not match? There's really only three criteria in it
a) the first packet of the connection is not incoming
b) it's incoming, but not on interface fxp0
c) the source address of the packet, when incoming on fxp0, is
not in table <abuse>
The first two can be checked with tcpdump, run
# tcpdump -nvvveeepi fxp0 host 24.147.44.26
then wait until you see one such packet. The ethernet header (source and
destination MAC address) will tell you which direction the packet had
(incoming would show as your own MAC address as destination), the mere
presence of any output shows that the interface involved was indeed
fxp0.
The third is checked with
# pfctl -t abuse -vvTt 24.147.44.26
but you mentioned you already tested that. Try testing it immediately
after you see the packet logged by tcpdump, maybe something is modifying
the table in the background.
And, equally important, show us how the packet actually passes. All your
pass rules are keeping state, so any connection will lead to a state
table entry. Can you find an entry from 24.147.44.26 with
# pfctl -vvvss
If so, the "rule N" part tells you which rule the initial packet of the
connection matched, corresponding to the rule @number printed by
# pfctl -vvsr
If you don't see any such state entry, the only other explanation is
that all packets of that connection don't match ANY of your rules, which
is impossible due to your broad default block rule
block drop log all
You don't have any "set skip on fxp0" option that I can see, so the only
explanation left would be that pf isn't enabled at all, but I assume you
checked that earlier, with
# pfctl -si | head -n 1
In this case, you have to prove that the pf box is actually seeing the
packet you want blocked, and is actually forwarding it instead. Try to
get a tcpdump on all involved interfaces and capture one packet incoming
on fxp0 and leaving on the internal interface. If you can't, how do you
know pf is passing it? For instance, there might be another gateway
besides pf which can forward packets to the server.
Daniel
[1] "Watson, as I have said, whenever all other possibilities have been
ruled out, the improbable, however unlikely, must be the truth."
-- Sherlock Holmes and the Case of the Vanishing Robbers
