pfBlockerNG block local DNS lookup
-
The instructions read
Select the 'Order' of the Rules
Selecting 'original format', sets pfBlockerNG rules at the top of the Firewall TAB.
Selecting any other 'Order' will re-order all the rules to the format indicated!I interpret that has reordering all my pfsense rules. I have my rules in the order they must be executed and putting all my pfsense pass rules before pfsense reject rules will not work.
It seems that the only way out is to disable/delete the faulty blacklist until this is fixed. There should be an easier way, mistakes can happen.
-
Click on the blue infoblock Icon for the "ACTION" setting.
You can use "ALIAS type" Action settings and manually create your own rules.
-
@bbcan177 I may just be dense here but I do not see how this changes thing. To illustrate my problem, please see the following rules
pfB_DNSBLIP contains the 192.168.1.1 IP which I need to allow. I am allowing this in pfB_PermitOutbound, which is however executed after pfB_DNSBLIP. If I move pfB_PermitOutbound to the top, everything works fine, but the pfBlockerNG update process recreates the rules and original order, thus preventing 192.168.1.1 to pass. This problem seems to be the same whether I define 192.168.1.1 as an alias or put it in a custom list set to "Permit Outbound".
Am I thinking about this wrong?
-
This thread seems to deal with the same issue but I am not sure I understand. The problem seems to be that all pfB deny rules are generated at the top of my rules table and I am do not know how to place a superseding permit rule at the top even if an alias is used.
-
@revengineer said in pfBlockerNG block local DNS lookup:
This thread seems to deal with the same issue but I am not sure I understand. The problem seems to be that all pfB deny rules are generated at the top of my rules table and I am do not know how to place a superseding permit rule at the top even if an alias is used.
Are you using pfBlockerNG-devel?
RFC 1918 addresses should have been filtered out automatically.
-
@bbcan177 No I am using the non-devel version.
-
@revengineer said in pfBlockerNG block local DNS lookup:
@bbcan177 No I am using the non-devel version.
Upgrade to pfBlockerNG-devel, there are so many fixes around Rule ordering and sanitizing of IPs.
-
@bbcan177 So you are saying this upgrading would fix this particular issue? (I have been hesitant because I am worried about things breaking.)
-
@revengineer said in pfBlockerNG block local DNS lookup:
@bbcan177 So you are saying this upgrading would fix this particular issue? (I have been hesitant because I am worried about things breaking.)
There is a monumental task to backtrack changes in pfBlockerNG-devel -> pfBlockerNG, its too much work and no time to do that on my own free time.
You have options:
- Stay with pfBlockerNG:
- Enable "Suppression" in the general tab, that should remove any RFC1918 addresses that it finds. I am not 100% sure if that covers DNSBL IP tho, would have to test it.
- Use Alias Type Action settings if none of the pre-defined Auto-Rule ordering works for your needs.
- Move to pfBlockerNG-devel:
- Which is what I recommend
- It is being actively supported and developed.
- I try my best to address any issues as they are found.
-
@bbcan177 Thank you, thank you, thank you!!! The "Suppression" option was disabled and enabling fixed the problem. The 192.168.1.1 IP is now begin removed from the URLhaus blacklist.
I think I also now understand the ALIAS solution. I would need to convert ALL pfB lists to aliases and completely forgo the auto rules. This seems to be good practice in general and I may consider this.
Finally, I do plan on updating to the devel version eventually, probably when I update to pfSense 2.5.0 in the future. This will take some time and I need to make sure I carve the time out from my schedule to address the issue. Right now, I am too busy at work and need the internet to just work for my video conferences.
