PF Understanding default logging behavior in PF

In trying to eliminate variables I've got the simplest setup I can think of, a fresh install of FreeBSD with one connected interface using a static IP which is directly connected to the cable modem. If the server specs are considered relevant I can dig them up.
My pf.conf reads:
Code:
block log all
pass all
I expect blocked traffic to be logged, though all traffic should pass so nothing should be logged, but if I curl the server from another network pflog reports blocked tcp packets. I do get the http page but I dont understand the blocked packets.

I read a post on a similar problem, Thread pf-rules-logic.63381, and added a normalization step:
Code:
scrub in on em0 all fragment reassemble
but the frequency of blocked packets only seems to increase.
I wouldnt generally nitpick about logs, but this behavior could be the root of a problem on another, more complicated setup.

Any thoughts or recommendations?
 
All rules are evaluated in order. So your block rule is always being hit and thus getting logged.
 
Do you mean the block rule can produce a log regardless of whether it is the last match?
It logs the hit of the rule.

Code:
    log   In addition to the action specified, a log message is generated.
 
It logs the hit of the rule.

Code:
    log   [Regardless of] the action specified, a log message is generated.
Ok, so the action specified is overridden by subsequent matching rules, but the log is issued upon matching.

To confirm this, I added the log keyword to the pass rule as well and you're right, it does log both actions. Odd thing is the first rule matched was logged after the second, but with an earlier timestamp.

I could see how this behavior might be useful on larger rulesets, but it was unexpected.

Thanks for taking the time SirDice
 
Yeah, use that log keyword sparingly. I generally only use it for logging successful connections (i.e. traffic I allow). I really don't care about all those bots scanning closed ports 👿
 
Yeah, use that log keyword sparingly. I generally only use it for logging successful connections (i.e. traffic I allow). I really don't care about all those bots scanning closed ports 👿
I had tried to log all blocked traffic, then use tcpdump to only show my network traffic so I could diagnose an issue. I'll need to rethink this.
 
I had tried to log all blocked traffic, then use tcpdump to only show my network traffic so I could diagnose an issue.
No need to log all blocked traffic. Just run tcpdump(1) with a good filter on the incoming interface to see the traffic. If there's no response it's being blocked. No need to check pflog0 for that. It's only useful if you have any specific block rules, something like block in log from <badhosts> to ($ext_if) for example. But if you know you have a rule like that it's just as easy to quickly verify the contents of that table.
 
Back
Top