pfBlockerNG: when configured to use floating rules, blocks both directions even for unidirectional rules
-
[in 25.03.b.20250515.1415]
As a test I changed pfBlockerNG to use floating rules instead of the per-interface rules I had always used. It did not go well, I got immediate blocking of everything going out on the WAN.
The cause seems to be the MAIL spammer IP list configured:
It is configured to deny inbound only, so it doesn't make any sense to block the outgoing direction.
I checked the floating rule, and it had direction "any" configured. Once I changed it to "in" traffic started to flow out of the WAN again. Every generated floating rules seems to be bi-directional, SCANNERS for example
gets this floating rule
whereas it should have been a
Anyone else seen this behaviour when pfBlockerNG is configured for floating rules?
-
What does the created rule show for direction? Looks like 'any from your screenshot there.
Did you have that setup in 24.11?
-
@stephenw10 All rules from pfBlockerNG are generated with direction "any", regardless of the "action" in the pfBlocker configuration.
Unfortunately, I did not run with floating rules in 24.11...
-
@pst said in pfBlockerNG: when configured to use floating rules, blocks both directions even for unidirectional rules:
I got immediate blocking of everything going out on the WAN
... and this got me wondering... why did everything get blocked... Quite humourous actually, it looks like there is a complete block of the ISP subnet that I am currently on, the whole /16 is included in the MAIL spammer IP list. Not sure why though, port 25 is filtered so there's little mischief to get up to in these residential neighbourhoods </saturday_musings>
-
Ok that isn't a regression in 25.03. it also creates direction any floating rules in 24.11.
You should probably open a thread in the pfBlocker sub for this.
-
@pst said in pfBlockerNG: when configured to use floating rules, blocks both directions even for unidirectional rules:
there is a complete block of the ISP subnet that I am currently on
It is what you want, if you are hosting a mail server: No connections from "residential IPs". I wouldn't have thought though, that these are available to us in that feed.
And I have disabled that feed because of false-positives in the past. -
@stephenw10 said in pfBlockerNG: when configured to use floating rules, blocks both directions even for unidirectional rules:
You should probably open a thread in the pfBlocker sub for this.
Or, I could just try and fix it myself...
I checked the code in pfb_firewall_rule (/usr/local/pkg/pfblockerng/pfblockerng.inc), and there is some bizarre logic for determining the direction of a rule. For "Deny Incoming" for example, there has to be a non-default gateway defined, which doesn't make any sense to me, logically.
But a work-around to my problem is to (per feed) change the Andanced Inbound Firewall Rules Setting / Custom Gateway / to something other than "default". Only then will the floating rule direction match the pfblocker direction.
Perhaps @BBcan177 can add some insights to this behaviour?
And @stephenw10, could you move this thread to the pfblocker sub? It is, as you say, not related to 25.03-beta.
Thanks
