Reject rule is getting logged as a block action
-
I have a reject rule set up as described in this log text:
The rule that triggered this action is:
@152(1441752613) block return in log quick on bridge0 inet from any to <local_subnets:3>label "USER_RULE: Reject egress to other subnets"</local_subnets:3>
But when I see the action appear in the Firewall log, it shows up as a block, not a reject. My ping tool also responds as if the ICMP packet was blocked and not rejected.
Here's a screenshot of the configuration UI, just to prove it.
Why isn't the reject action working as configured?
-
Reject only rejects TCP and UDP. ICMP errors aren't to be returned for ICMP traffic per RFC, so you don't end up with a never-ending loop of errors.
pf only logs either block or pass, so your logs will show block even for rejected traffic.
-
pf only logs either block or pass, so your logs will show block even for rejected traffic.
Do you mean that pfSense only logs the text "block" or "pass"? Or do you mean it only logs block and pass rules? Because the rule that was logged wasn't a block rule, it was a reject rule.
-
@cmb:
Reject only rejects TCP and UDP.
But I can configure the rule to "reject IPv4 and IPv6 on any protocol". Why is that a config option if it doesn't work that way?
-
Rejects are always logged as blocked.
It can be specified with any rule type because there's no reason to restrict it. It'll reject where applicable. Years ago it used to require specifying TCP and/or UDP only, but that just resulted in unnecessary duplication of rules.
-
@cmb:
Rejects are always logged as blocked.
Oh. That isn't obvious to a new user, and I don't think it's in the documentation anywhere. Thanks for clarifying it for me.
@cmb:
It can be specified with any rule type because there's no reason to restrict it. It'll reject where applicable. Years ago it used to require specifying TCP and/or UDP only, but that just resulted in unnecessary duplication of rules.
From the perspective of configuring a ruleset, there might be no reason to restrict the selections available. But from the perspective of trying to debug a ruleset that isn't working as desired, the more explicitly consistent the stated configuration is with the logs, the easier it is to correlate a given configuration option (rule) to the resultant behavior. So much of my experience with pfSense has been frustrating because the actual behavior doesn't correlate well to the configuration I think I'm setting up. (Given the number of recent threads about unexpected firewall behavior, I'm inclined to think I'm not alone.)