pfblocker-devel does not block ip

lbm_

Im having some traffic, which keeps coming in, on my mailserver, which I would like to block with pfblocker-ng-(devel). Its version "2.2.5_29"

I've created an custom IP IPv4 category, and it seems to work. If I set the direction to "Deny both" I cannot access the blocked IP anymore, but traffic keeps coming in. I can see in the logs on the targeted server, and I also get this with tcpdump on the same server. (ips, masked)...

14:34:40.037124 IP (tos 0x0, ttl 49, id 19471, offset 0, flags [DF], proto TCP (6), length 60)
    XXX.26332 > YYY.587: Flags [S], cksum 0x9c18 (correct), seq 888453245, win 29200, options [mss 1460,sackOK,TS val 2221667442 ecr 0,nop,wscale 10], length 0
14:35:03.020934 IP (tos 0x0, ttl 49, id 3436, offset 0, flags [DF], proto TCP (6), length 60)
    XXX1.29660 > YYY.587: Flags [S], cksum 0xfe80 (correct), seq 3773580117, win 29200, options [mss 1460,sackOK,TS val 2221690425 ecr 0,nop,wscale 10], length 0

alt text

What am I missing here ? Is it because there are is an NAT rule, which overrides this ?.

--edit--
Just enabled the "Kill States", but the issue persists.

--edit again--
So, NAT rules are passed before custom rules, which must be why..
https://docs.netgate.com/pfsense/en/latest/firewall/firewall-rule-processing-order.html

I've changed the NAT rule, to the source does NOT match my pfblocker block alias rule, which is working. BUT, I can only apply one of these.

lbm_

Ok, so I think I got this working.

I've created an alias under firewall rules with "networks" as type, where I have the added the pfBlockerNG names of the lists I have enabled under IP/IPv4 and IP/GeoIP.

Then for the NAT rules, i've added this alias as "inverted" source.

So, if I add/modify these lists, then the alias needs to be modified as well. Not an very big deal for me, but could be for others ??

But maybe im missing a magic checkmark, so this happens automatically? :)

NollipfSense

@lbm_ said in pfblocker-devel does not block ip:

I've created an alias under firewall rules

There, you go...that's exactly what I would say.