Floating rule pfB_DNSBL_Permit in|out|any

[NollipfSense]

@billl Bill you asked a mouthful ... could you see if these two links could help you answer your questions: https://docs.netgate.com/pfsense/en/latest/firewall/floating-rules.html ... https://docs.netgate.com/pfsense/en/latest/packages/pfblocker.html From LAN, the DNSBL should be reject. Also check these as well: https://forum.netgate.com/topic/120748/pfblockerng-changing-the-order-of-my-own-floating-rules/2
https://forum.netgate.com/topic/125250/firewall-rules-order

[billl]

@NollipfSense said in Floating rule pfB_DNSBL_Permit in|out|any:

https://forum.netgate.com/topic/125250/firewall-rules-order

Thank you for the suggestions. I think I've already read each of those pages several times, but I read them again just to be sure :)
I'm not using automatic rule generation from Firewall / pfBlockerNG / IP (I use Alias Deny there), and the rules that I'm referring to are related entirely to DNSBL, not the IP stuff. I'm also not having any issues with re-ordering of rules.
thanks!
Bill

[NollipfSense]

@billl Okay ... to me, it seems that nothing should break a floating rule especially if you have quick set checked. From the pfb_DNSBL_Ping would be set to direction "in" and pfb_DNSBL_Permit direction "out."

[billl]

@NollipfSense Thank you! I'm afraid I'm not following what you mean by "nothing should break a floating rule", but perhaps addressing the following will help clear things up:
The direction properties of pfB_DNSBL_Ping or pfB_DNSBL_Permit are just as pfBlockerNG-devel created them, and both have their direction set to "any". I have been trying to gain an understanding of the how, what, when and where of the traffic that these rules are intended for, and I thought the direction "any" added a dimension that is probably important to their nature. I think I get the notions of "in" being to instruct evaluation of traffic arriving in through an interface (as is the case with non-floating rules), "out" being to evaluate traffic going out through an interface (as one might want to do with a WAN interface), and "any" meaning both "in" and "out".
Since asking my question, I had a SMH moment when I noticed that the states of both rules are 0B:

so, before I go any farther, I need to learn under what conditions these rules come into play at all. I am starting to wonder if they are left over from pfBlockerNG, from before I switched over to pfBlockerNG-devel ..

For the record, here are the NAT Port Forwards as created by pfBlockerNG-devel:

that all seems to be working as I expected (thus my question 2, if VIP:443 has been translated into 127.0.0.1:8443, how does a rule for VIP:8443 come into play?)
thanks for your help!
Bill

[billl]

Ok, I'm pretty sure the rules pfB_DNSBL_Ping and pfB_DNSBL_Permit are not a vestige of my old pfBlockerNG, as I upgraded to pfBlockerNG-devel a while back, and a recent config file shows them to have a recent date (they were apparently recreated by pfBlockerNG-devel the last time I did a reload):
<created>
<time>1596854818</time>
<username>Auto</username>
</created>

[NollipfSense]

@billl said in Floating rule pfB_DNSBL_Permit in|out|any:

The direction properties of pfB_DNSBL_Ping or pfB_DNSBL_Permit are just as pfBlockerNG-devel created them, and both have their direction set to "any".

I thought you said earlier that you created your own here: "I'm not using automatic rule generation from Firewall / pfBlockerNG / IP (I use Alias Deny there)." So, I am confused.
Floating rules with the quick set checked are processed before other firewall rules Those floating rules do have the quick set checked, and the 0/0B says you have not processed anything yet. I am not at my system to see what I got but don't recall having those.

Let's hope other more familiar will chime in.

[billl]

@NollipfSense some of the links you sent me were about automatic rule generation from Firewall / pfBlockerNG / IP. I don't use those (I use Alias Deny and handle rules for those lists manually, and not in floating).

pfB_DNSBL_Ping and pfB_DNSBL_Permit are, as I understand things, different animals that are specific to DNSBL. pfBlockerNG-devel creates them as floating rules (with no regard to choices made in Firewall / pfBlockerNG / IP, as far as I can tell), and assigns them to the interfaces that were selected in Firewall / pfBlockerNG / DNSBL / Permit Firewall Rules. I confirmed this by removing an interface selected in Firewall / pfBlockerNG / DNSBL / Permit Firewall Rules, reloading and looking at both floating rules pfB_DNSBL_Ping and pfB_DNSBL_Permit to see that the interface had been removed from them.

Yes, indeed, I would think that if any traffic was getting generated that went through any of the assigned interfaces, and matched these rules, it should hit them. Maybe I'm not exercising use cases that would do this. I would still love to understand the concepts behind the rules though ..

[billl]

@NollipfSense BTW, thank you again for all of your help with this. I'm going to ping @BBcan177 in hope that he can spare some time for it.
thanks!
Bill

[NollipfSense]

@billl Okay, I see what you're speaking of ... you really don't need to enable that if you're not understanding it ... I don't have it enabled.

Also, here is my floating rules which focus on IP's. By the way, I love floating rules with the quick set checked. WAN blocks and LAN reject. BBcan177 had been really busy.

[billl]

@NollipfSense Thank you :)

I wonder if the text
"This will create 'Floating' Firewall permit rules to allow traffic from the Selected Interface(s) to access the DNSBL Webserver (ICMP and Webserver ports only)."
has become out of date in the latest release, or maybe it only applies to use cases involving CARP.

In my (multi-LAN (via VLANs), non-CARP) use cases at least, all traffic that I've seen redirected by pfBlockerNG-devel DNSBL gets addressed to the virtual IP on ports 80 and 443 (not ports 8081 and 8443). This traffic NATs via port forward to 127.0.0.1 ports 8081 and 8443, and gets a pass via 'associated rule=pass' directly from the NAT port forwards.

The only way that I have been able to generate any traffic that hits the pfB_DNSBL_Permit rule is by deliberately (you could say unnaturally) targeting the following URLs (where $vip is the DNSBL Webserver's Virtual IP address):
http://$vip:8081/
https://$vip:8443/
Maybe being able to reach these forced addresses could be useful for testing, but that doesn't seem to warrant the checkbox on the UI.

If anyone can describe a use case where access to the DNSBL Webserver via $vip:8081 or $vip:8443 is necessary, please help to satisfy my curiosity and perhaps save some newbs from confusion :) There are pages on the internet for basic configurations that instruct folks to enable this, and the UI certainly suggests it, to me at least.

In the meantime, I will follow NollipfSense's lead and disable DNSBL Configuration, Permit Firewall Rules. It's always nice to eliminate code!
Thanks!
Bill