pfBlockerNG-devel v3.1.0_9 / v3.1.0_15
-
Hi
I was reading about the DoH/DoT/DoQ Blocking feature in DNSBL SafeSearch of my
pfBlockerNG-devel v3.1.0_9.
As far as I have understood it, it blocks clients on my LAN to use DoH/DoT, so
I was wondering if this feature can also affect DoT queries from Unbound itself since I enabled DoT in its setting.
Thanks
-
This post is deleted! -
@sensei-two I believe it does. I use unbound to funnel all public DNS queries to Cloudflare over DoT. But I took a different approach to blocking all other DoT/DoH.
I have pfB-NG creating a deny alias using these blocklists:
https://raw.githubusercontent.com/Sekhan/TheGreatWall/master/TheGreatWall_ipv4
https://raw.githubusercontent.com/Sekhan/TheGreatWall/master/TheGreatWall_ipv6Then I created rules on the LAN-side interfaces that destination blocks the aliases that these blocklists create.
Unbound should be using your WAN interface to reach your DoT provider and it won't have an ingress interface (i.e. there's no LAN-to-WAN or WAN-to-LAN flow). The only way I think you could control the firewall's own egress-to-WAN would be using a floating rule.
-
I also use Unbound to funnel DNS queries to Cloudflare over DoT,
so, in your opinion, if I now enable the DoH/DoT/DoQ Blocking feature in pfng something might be wrong with my "legitimate" DNS queries over DoT, right?I am interested in your approach to block DoT from LAN's clients, but I new to pfblockerNG, and I didn't use pfSense for a long time either, so bear with me, please.
Could you tell me how to set the deny alias using the blocklists above, please?
Should I delete my floating rules if I create the new rules on the LAN-side?
My floating rules:
Thanks
-
@sensei-two It's been a while since I looked at the DoT/DoH blocking in pfB-NG, but I thought it creates floating rules, which would impact the unbound service's egress out of the WAN interface (as well as any other interface) unless you configure the floating rule to exempt the WAN address. The problem I see with that is that you can't generally edit auto-generated rules because they are overwritten after an update cron job.
Maybe that has since been fixed in pfB-NG? I don't know for sure. I can only speak to my solution, which I have tested and know works in my environment for the DoT and DoH providers in those blocklists.
I have pfBlocker-NG creating these aliases. These can probably be Alias Native instead of Alias Deny. My understanding of de-dup and reputation should be irrelevant in my config. IPv4 details shown here. I have an identical IPv6 one, as well.
Then assign these aliases to block rules near the top of your LAN side, before anything that might allow them.
-
Ok, I think I have understood how to set them, and
I'm going to give them a go.
This way you can do without the DoH/DoT/DoQ Blocking feature in DNSBL SafeSearch, can't you?
Out of curiosity. Did you also try the DoH/DoT/DoQ Blocking feature? If so, did you stumble upon some issues because of it?
Thanks -
@sensei-two I honestly don't remember. I probably did. I have a couple subnets where I do allow less restricted outbound access, so it's possible I did this just to have more control.
Looking at the feeds, I also threw these into the custom IP lists (IPv4 and IPv6, respectively) at the bottom since they weren't covered by the feeds themselves.
1.0.0.2/31
1.1.1.2/31
2606:4700:4700::1002
2606:4700:4700::1003
2606:4700:4700::1112
2606:4700:4700::1113I noticed you mentioned DoQ, as well. For completeness, here's how I'm blocking everything DNS-related on my guest subnet except for my unbound resolver.
-
Very helpful. Thank you very much indeed
-
This post is deleted! -
This post is deleted! -
I came up with these firewall rules:
I had already set a NAT rule for dns redirection which makes its work:
In order to test the DoH/Dot block rules I enabled DoT in the Firefox browser of one on my clients, but it seems that it doesn't work.
The client gets access to webpage nonetheless.
What did I get wrong? ThanksUPDATE!
I also see this log:
maybe the browser is being redirect to port 53 if DoH queries can't be resolved because of the new pf_rules I added.
Any thought? -
@sensei-two said in pfBlockerNG-devel v3.1.0_9 / v3.1.0_15:
maybe the browser is being redirect to port 53 if DoH queries can't be resolved because of the new pf_rules I added.
Any thought?If you are talking about Browsers using DoH - there normally should be fallback to a system's DNS setting if no DoH can be established for exactly that case. AFAIR Firefox etc. have a setting to disallow that to "avoid" being redirected to a "bad/controlled DNS" but in a home/company setting that's exactly what you want because otherwise many internal domains/services are unavailable (as they are often non-public DNS entries). But that discussion has become way out of scope of that post here, where the topic is about the new version and problems/bugs that may happen with it. Please put posts about usage/config problems of a feature in a separate post (as that feature wasn't introduced in version 3.1.0_9 / _15) for better visibility :)
Cheers
\jens -
@jegr
I might be wrong, but it is exactly what seems to have happened with Firefox too: it switched to my system DNS.
Anyway, as you say, I'll post about the issue elsewhere, to dive deeper into it possibly.
Thanks -
I am copying this over another user noticed in 3.1.0_1 that I am seeing still currently present in 3.1.0_9. I have IPv4 whitelists that carried over from pfSense 21.05 my box shipped with, used to be able to edit and add IPs when I needed. Now I find that unless I am whitelisting IPs via the alerts tab itself, if I try to edit any of these custom lists manually I am facing this same "Warning: When using an Action setting of 'Permit Inbound or Permit Both', you must configure at least one of 'Advanced Inbound Custom Port/Destination' settings." as well as a "Improper Permit rules on the WAN can catastrophically impact the security of your network!" error detected. This is also verified when trying to create a new rule from scratch, even with attempting to set IPv4 main screen interface rules config for inbound rules to LAN instead of WAN as it was and should be:
Tueurdragon wrote on https://forum.netgate.com/topic/176439/error-on-permit-inbound-rule-ipv4-part :
Error on Permit Inbound rule IPv4 part
pfBlockerNG 1 2 192
TTueurdragon Dec 13, 2022, 11:19 AM
Error on Permit Inbound rule IPv4 partHi there,
I have a problem creating a Permit Inbound rule in the PFBlockerNG-devel module IPv4 part.
Indeed, I want to create a Whitelist before all the GEOIP blocking rules.
SETTING part
Here are the things that I provide:
Action: Permit Inbound
Update Frequency: never
Weekly: Monday
Auto-Sort Header field: Enable auto-sort
Enable logging: Enabled
States Removal: EnabledPart Advanced Inbound Firewall Rules Settings
Custom DST Port: checkbox check , in the input field I enter an alias
Custom Destination: checkbox check, in the input field I enter an alias
Custom Protocol: TCP
Custom Gateway: I choose my gatewaygroup because I have several WANs in failoverUnfortunately I always get this error
The following input errors were detected:
Warning: When using an Action setting of 'Permit Inbound or Permit Both', you must configure at least one of 'Advanced Inbound Custom Port/Destination' settings.
===> WARNING <===
Improper Permit rules on the WAN can catastrophically impact the security of your network!
And the Custom DST Port and Custom Destination input fields are cleared.Can you help me?
Thanks in advance,0
TTueurdragon 28 days ago
Small clarification,I have another PFSENSE firewall with the PFBlocker-NG module in version 3.1.0_1 and it works but obviously it no longer works on the PFBlocker-NG version 3.1.0_7
-
@smoke_a_j said in pfBlockerNG-devel v3.1.0_9 / v3.1.0_15:
When using an Action setting of 'Permit Inbound or Permit Both', you must configure at least one of 'Advanced Inbound Custom Port/Destination' settings
There was a different thread about this a few weeks ago. If you allow all inbound traffic to your WAN IP on all ports then the IPs specified can access pfSense via SSH, HTTPS (web GUI), DNS, etc. Meaning, attackers can continually guess passwords until they get in.
The warning is so you don't allow that.
If you really wanted to open your pfSense to the Internet you could create these as Alias Native which only creates the alias, and then create your own rules on the WAN interface using that alias.
-
@steveits That is understood, that's why I have an alias set for Mirosoft ports for certain specific work apps and xbox live logins as well as a separate alias set for my wifi calling ports, same recommendations existed in pf 21.05 and the firewall rules as well as the IPv4 tab used to compile all of this just fine. These alias' have no http, https, DNS, or ssh ports listed in them and further verified with having WAN de-selected and had this Custom Port option enabled and alias name typed out correctly each time. Appears to me more of a PHP or XML coding issue in 22.7 config versions, and I found came about recently when repos got set to temporarily showing that pfSense 23.01 stable was available but since https://firmware.netgate.com/pkg/ was not updated at the same time to coincide, my repos config became corrupt from it landing both of my boxes in non-fixable certificate errors at boot needing to start from scratch. This is now verified on 2 different devices, one is a NG 5100, and both are freshly setup once again days ago from flash. Obviously having "all" ports open is a common sense no no to any networking hence the entire reason of having a "custom port" option for an alias. The point of this post is these errors are persistent with the correct entries filled and applied. Basically from what you are saying is that "inbound permit both" simply is not an option and therefore would not exist with these "custom options" to configure, but in reality these configuration option realistically are there and there for a reason and used to function for that reason. This exact situation is occurring on one of my boxes that does not even have a "WAN" interface configured to even select, LAN only serving only DNS as a parental locked pi-hole basically, all of which is still working fine. Also noting that each time attempting to edit or create a new IP whitelist, once each of these custom options are specified on Advanced Inbound Firewall Rule Settings and then try to save, once these errors are displayed when the page loads, scrolling back to the custom options the enable tic box does remain ticked but the fields to enter the port alias/IP alias name in becomes emptied and grayed out with the red circle with a line through it as I hover over the entry field until I un-tick the enable option and then re-select it and then the entry field becomes available to enter the alias name into again; I'm leaning toward PHP since no other pfSense configurations or functions seem to be affected, just editing or creating from the gui on the pfblockerng_category_edit.php pageregardless if its IPv4 or IPv6 whitelists
-
@smoke_a_j I missed that you set a port alias. Does it work with one port number instead of an alias?
If it is a bug, then creating the pfB alias and manually creating your own rule ought to work around it.
-
@steveits Even just one listed in an alias does the same. pfB alias permit is a working feasible workaround with "permit both" broken, auto rule function is/was nice and safer to configure with those warnings accurately working to make sure the custom fields are in fact filled out but somehow the validation of that fact looks to be clearing the data entered instead of reading it, maybe one letter off in the code like a "W" instead of an "R"
-
This post is deleted! -
@sensei-two
@xpxp2002
Something that may help you with the above to make sure everything is hitting the firewalls right:
for NAT port forwardsand
for Outbound NAT
