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
-
S stephenw10 moved this topic from Plus 25.03 Develoment Snapshots
-
@pst Auto rules are added one size fits all and they can be modified somewhat with the Advanced in/outbound settings. Otherwise, if needed, use Alias Type such as "Alias Deny" and manually create your firewall rules as needed. Click on the blue infoblock icon for the Action setting for more details on that.
