Did pfSense change reject behavior on a recent update?
-
On my internal lans I have the rule at the bottom set to reject all packets to override the default block; like this:
Before I updated my system to 25.11-RELEASE, when I looked in the firewall logs packets that hit the reject rule showed the yellow hand and it looked like the rule worked as intended. Now I notice that the firewall logs no longer show the yellow hand for packets that stop at the rule; I see the red "x" symbol which I thought only applied to packets that were handled with a block rule. Additionally, when I now hover over a rule that is handled by the reject rule, the dialog says the action is block:
I performed some packet captures and I do get TCP RST when packets are handled by the reject rules I describe above, so it seems to be doing the right thing internally. I just seem to remember that some time in the recent past the firewall said it was performing a reject instead of a block.
Does this make any sense to anyone and did something change with either the firewall log display or how packets are handled or I just dumb? And why does the action of the rejected packet I posted above say "block" instead of "reject"?
-
@whanlon let me take a look, I run some rejects on my lan as well.
-
@whanlon they changed how floating match rules work.
https://docs.netgate.com/pfsense/en/latest/releases/25-11.html#:~:text=Fixed:%20Filter%20rule%20evaluation
-
@whanlon so now you have me wondering, vs looking through logs for hits on my rejects - I just created a new rule.. And then triggered it.
And your right the log just shows X (block)... So now trying to recall if before did you use to show the reject hand, etc..
But I did do a sniff while testing the rule - and did get the icmp notification of being denied, ie reject.
But yeah you would hope the log would show reject vs block, if what is triggering is a reject rule. hmmm - have to look through redmine if has been reported.
I will also have to fire up my 2.8.1 vm and see what it does.
-
@johnpoz I know that the logs used to mark the rejected packets with the yellow hand. I monitor the logs regularly to ensure I am not preventing outbound traffic that users need. I don't recall what the "rule details" dialog said for "action" though unfortunately. Maybe it is just cosmetic, but the action says "block", not "reject". Perhaps that is an error. I'm not sure.
@SteveITS I don't have any explicit floating rules set, so I am not sure how it applies to my example. Are there implicit quick rules set that don't show up in the psSense GUI that could cause this behavior?
-
@whanlon yeah agree, but personally I don't recall for 100% but I do seem to recall in the logs it was hand.. What is weird is showing block but still does send the reject..
I am about to head out, but when get some time will check with my 2.8.1 vm and look through redmine to see anything there related.
-
@johnpoz I added a block rule below by existing reject rule and took a look at /tmp/rules.debug, which has the current set of rules in effect (https://docs.netgate.com/pfsense/en/latest/firewall/pf-ruleset.html).
It looks legit. These are the rules that are in place:
block return in log quick on $VUSER_LAN inet from $OPT4__NETWORK to any ridentifier 1756936730 label "id=1756936730" label "tags=user_rule" label "descr=Reject ALL VUSER_LAN traffic to ANY" block in log quick on $VUSER_LAN inet from $OPT4__NETWORK to any ridentifier 1768607449 label "id=1768607449" label "tags=user_rule" label "descr=Block ALL VUSER_LAN traffic to ANY"My fundamental misunderstanding was that "block return" is the pf rule to "reject". And my screenshot shows that the action is corrected described as "block" and the rule "block reject" is also correctly show in the ruleset dialog. Given that @johnpoz and I both see the correct behavior of how packets are handled, there is no issue with the firewall itself. I do think that there was a cosmetic change though. These rejected packets used to have the yellow hand icon displayed in the action column of the firewall log, but now they have the red "x" like all packets that are blocked WITHOUT returning a RST or ICMP type 3. @johnpoz may be able to verify that with a VM.
Thanks for the quick replies.
-
@whanlon maybe the return is just cut off in the log now, and so you see the normal block symbol - clearly its just cosmetic it seems if you cut off "block return" and just show block in the action row.. maybe it shows the wrong image is all. The rule there does show return, and does send it.
-
@whanlon ok well its normal in 2.8.1
It shows the reject hand in the log, and action is reject - rule is the same "block return" and it does send the reject via icmp just like 25.11 is doing.
So yeah clearly it changed.. will have to look through redmine to see if listed.. But yeah it should be put back to showing the little reject hand in the logs.
Same test created a rject rule, log it.. send traffic
edit: ok I didn't see anything in remine about this, so opened a new issue
-
@johnpoz Thanks for verifying and submitting the bug report.
-
@whanlon np - while it it seems to be only cosmetic, since it does send the reject.. I would think should be a simple fix.. But then again I might be just assuming its easy.. Lets hope it can make it into 25.11.1 or 26.03
-
@whanlon this seems to have been fixed
-
@johnpoz Cool!
