Did pfSense change reject behavior on a recent update?
-
@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!
