Floating rule pfB_DNSBL_Permit in|out|any

[billl]

I have questions about the direction property for floating rules pfB_DNSBL_Ping and pfB_DNSBL_Permit, and also related to the port property for pfB_DNSBL_Permit, but would first like to present my understandings of the context for your review and corrections:

Supposing the DNSBL Webserver Interface has been assigned to LAN and the local interfaces consist of LAN(igb1), OPT(igb2) and VLAN10(on igb1), and the interfaces selected in the section Permit Firewall Rules are LAN, OPT and VLAN10 (perhaps LAN doesn't need to be selected here, but that may be another matter). In this case, pfBlockerNG creates NAT Port Forwards for the LAN interface to translate traffic destined for the Virtual IP address on ports 80 and 443 by redirecting it to 127.0.0.1 on ports 8081 and 8443 (if using defaults). (note: rather than linking to rules allowing traffic to 127.0.0.1 on ports 8081 and 8443, the Filter rule association for these port forwards is simply "Pass"). pfBlockerNG also creates floating rules pfB_DNSBL_Ping and pfB_DNSBL_Permit, and assigns them to the interfaces that were selected in Firewall / pfBlockerNG / DNSBL / Permit Firewall Rules.
These rules evaluate traffic through their assigned interfaces in direction "any", and pass quick when source is "any" and destination is the DNSBL Webserver's Virtual IP address (among their other criteria).

I also understand (hopefully correctly!) that when a floating rule's direction is set to "in", a floating rule operates very much like an interface rule, in that traffic is evaluated against the rule as it enters through any of the rule's assigned interfaces(s). Thus, source will always belong to one of the assigned interfaces' subnets.

Supposing a device on VLAN10 sends traffic to a domain name that is on an assigned DNS block list. It requests an IP for that domain name from DNS, and pfBlockerNG facilitates a response containing the DNSBL Webserver's Virtual IP address, effectively blocking that domain name. The traffic is allowed to proceed in through the VLAN10 interface and eventually reach the DNSBL Webserver because it gets a (quick) pass from floating rule pfB_DNSBL_Permit, and because the NAT Port Forward that matches it has a filter rule association of "Pass".

Here are my questions:

1. Please help me to understand under what circumstances things would break if pfB_DNSBL_Ping and pfB_DNSBL_Permit simply had the direction property "in", rather than "any".

2. pfB_DNSBL_Permit matches traffic on the DNSBL Webserver's Virtual IP address, which would be the destination address prior to translation by the respective port forward, but it also matches on the ports in pfB_DNSBL_Ports, which would be the ports after translation by the respective port forward. Please help me to understand the disparity here.

3. Would it be prudent to follow the floating rule pfB_DNSBL_Permit with quick block rule that matches anything with a destination equal to the DNSBL Webserver's Virtual IP address? If some local device has picked up evil code that tries to reach evilCorp, either on a non-http port or with some sneaky non-TCP/UDP protocol, and DNSBL responds with an IP of 172.16.6.6, then it seems to me like a good idea to immediately shut that down. Perhaps it would be a good idea for pfBlockerNG to also create such a pfB_DNSBL_Deny floating rule to follow pfB_DNSBL_Permit (configurable, of course)?

thank you,
Bill

[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