[solved] pfBlockerNG: when configured to use floating rules, blocks both directions even for unidirectional rules

pst

[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?

stephenw10

What does the created rule show for direction? Looks like 'any from your screenshot there.

Did you have that setup in 24.11?

pst

@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

@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>

stephenw10

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.

Bob.Dig

@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.

pst

@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

BBcan177

@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.

pst

@BBcan177 thank you, I'll just document my last findings from the 25.03 June10-beta in case someone else end up in the same situation.

My problem scenario involves a forwarding of port 25, configured in NAT / port forwarding.

Tracing on the WAN to see what's going on:

tcpdump -n -vvv -i igb0 port 25

In the working cases, when the Google Permit List is not included in the floating rules I get this in the trace. Google talks to the WAN.

00:16:26.663434 IP (tos 0x0, ttl 107, id 57837, offset 0, flags [none], proto TCP (6), length 60)
    <Google IP>.59813 > <My External IP>.25: Flags [S], cksum 0x14ae (correct), seq 2671406740, win 65535, options [mss 1412,sackOK,TS val 2651170751 ecr 0,nop,wscale 8], length 0
00:16:26.663797 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    <My External IP>.25 > <Google IP>.59813: Flags [S.], cksum 0x2f6f (correct), seq 2650828563, ack 2671406741, win 65160, options [mss 1460,sackOK,TS val 186830399 ecr 2651170751,nop,wscale 7], length 0
00:16:26.692077 IP (tos 0x0, ttl 107, id 57838, offset 0, flags [none], proto TCP (6), length 52)
    <Google IP>.59813 > <My External IP>.25: Flags [.], cksum 0x588a (correct), seq 1, ack 1, win 1054, options [nop,nop,TS val 2651170779 ecr 186830399], length 0
00:16:26.700570 IP (tos 0x0, ttl 63, id 50463, offset 0, flags [DF], proto TCP (6), length 92)
    <My External IP>.25 > <Google IP>.59813: Flags [P.], cksum 0xe793 (correct), seq 1:41, ack 1, win 510, options [nop,nop,TS val 186830436 ecr 2651170779], length 40: SMTP, length: 40

When I re-enable the Google Permit List, it starts to fail. In addition to Google talking to the WAN there is also Google talking to the internal NATed host, which does not work.

00:25:25.108743 IP (tos 0x0, ttl 108, id 29525, offset 0, flags [none], proto TCP (6), length 60)
    <Google IP>.42097 > <My External IP>.25: Flags [S], cksum 0x3c76 (correct), seq 3787317546, win 65535, options [mss 1412,sackOK,TS val 3190167796 ecr 0,nop,wscale 8], length 0
00:25:25.108777 IP (tos 0x0, ttl 108, id 29525, offset 0, flags [none], proto TCP (6), length 60)
    <Google IP>.42097 > <My ___INTERNAL___ IP>.25: Flags [S], cksum 0x6102 (correct), seq 3787317546, win 65535, options [mss 1412,sackOK,TS val 3190167796 ecr 0,nop,wscale 8], length 0
00:25:33.620747 IP (tos 0x0, ttl 108, id 29526, offset 0, flags [none], proto TCP (6), length 60)
    <Google IP>.42097 > <My External IP>.25: Flags [S], cksum 0x1b36 (correct), seq 3787317546, win 65535, options [mss 1412,sackOK,TS val 3190176308 ecr 0,nop,wscale 8], length 0
00:25:33.620786 IP (tos 0x0, ttl 108, id 29526, offset 0, flags [none], proto TCP (6), length 60)
    <Google IP>.42097 > <My ___INTERNAL___ IP>.25: Flags [S], cksum 0x3fc2 (correct), seq 3787317546, win 65535, options [mss 1412,sackOK,TS val 3190176308 ecr 0,nop,wscale 8], length 0

Now, if I change the generated floating rule, and manually remove the gateway from the rule, it starts to work again!

So, the gateway that pfBlockerNG requires to set the direction properly, also breaks the port forwarding.

I will continue with the suggested approach of Alias-rules and manually creating the fw rules.

stephenw10

If you set a gateway on an inbound rule in WAN it will force traffic to that gateway which is almost certainly not what you want. That's probably why it's breaking traffic there.

pst

@stephenw10 said in [solved] pfBlockerNG: when configured to use floating rules, blocks both directions even for unidirectional rules:

which is almost certainly not what you want

indeed, but pfBlockerNG "forced me to" , otherwise the direction on the generated floating rule would be wrong ('any') and blocking all my outgoing traffic (my initial problem).

Fortunately, there are ways around it as mentioned above, so all's good now.

stephenw10

Yeah, I would use auto generated aliases in user created rules personally. That gives you complete control with all the benefits of auto updating.