Thank you all. I managed to solve this issue by adding IPs under the Python Group Policy.

@michmoor said in Safari browser no longer works - Blocking private Relay: Is there anyway to get the response to be NXDOMAIN? That's what I see : [image: 1742542055723-f75323a7-4bb2-4830-ad9c-01ed14f47952-image.png] but still no joy. It looks like mask-h2.icloud.com doesn't exist ?! If have, like you, pfBlockerng Safesearch enabled with the entire list checked. Disabling it and, not surprisingly, it starts to work. C:\Users\Gauche>nslookup -4 mask-h2.icloud.com *** Option non valide : 4 Serveur : pfSense.bhf.tld Address: 2a01:cb19:dead:beef:92ec:77ff:fe29:392c Réponse ne faisant pas autorité : Nom : mask.apple-dns.net Addresses: 2a02:26f7:13c:0:ace0:a906:: 2a02:26f7:13c:0:ace0:a909:: 2a02:26f7:13c:0:ace0:a90b:: 2a02:26f7:13c:0:ace0:a903:: 2a02:26f7:13c:0:ace0:a908:: 2a02:26f7:13c:0:ace0:a907:: 2a02:26f7:13c:0:ace0:a90e:: 2a02:26f7:13c:0:ace0:a90d:: 172.224.169.11 172.224.169.12 172.224.169.13 172.224.169.14 172.224.169.4 172.224.169.8 172.224.169.5 172.224.169.10 Aliases: mask-h2.icloud.com What I make of it : when you use the Safari App, even if your iDevice has been set up to use the pfSense Resolver, when using the "Apple PrivateRelay service" then "DoH/DoT/DoQ" is used. And you've blocked that. So : unblock. Or : Stop using the (soon to be definct) Safari Browser. Btw : I know, Safari was part of the iDevice original story, but it some how lost the browser war ^^ I use it one in a while, but only as my second opinion browser when I want to double check my FF browser. @michmoor said in Safari browser no longer works - Blocking private Relay: The Logging/Blocking Mode is set to Null Block (no logging). To be honest I don't know the difference between this and Null Block (logging). My two cents : 0.0.0.0 or Null logging is best. The other one is "10.10.10.1" which uses to pfBlockerng build in web server so the user can see he was accessing an URL (host name) that was blocked. This only works for http sites - not https. Since everything is https (TLS) these days, this pfBlockerng functionality is ..... useless these days. Btw : "Apple PrivateRelay service" is Apple's way to show you that they want to protect you. Yeah ... cool ! Great ! ... wait : for free ? Serious ? It's just Apple way to force your browser, or more probably your entire iDevice, to use a DNS server from Apple so they can get their hand son your juicy DNS traffic, totally bypassing your pfSense local resolver and pfBlockerng. So, you have a choice to make edit : Why did I saw NXDOMAIN messages ? Probably because I did this : Null blocking SERVFAIL and you'll find "https://github.com/pfsense/FreeBSD-ports/pull/1407/files". I edited my /usr/local/pkg/pfblockerng/pfb_unbound.py copy with these instructions in the beginning in February (and actually forgot about up until now) so I guess these edits do their job without issues. From what I make of it, it correct some issues in /usr/local/pkg/pfblockerng/pfb_unbound.py. Not saying you have to apply these edits (who am I after all ^^), but they seem correct, and answer that feeling that I had that something was off when pfb_unbound.py was dealing with the unbound callbacks when a requested domain couldn't be found. NXDOMAIN was returned (as seen be packet capturing) but pfb_unbound.py = pfBlocker = eventually pfSense's unbound returned ServFail to the requester.

@hajun29011 said in dnsbl is not working properly: I definitely added naver.com to the custom list, but when I access it, it connects normally. There is no blocking log either. When I do not (!) add never.com here : [image: 1742491289970-57b628ad-ba2c-4d34-9b0b-777ae5ee91f4-image.png] and I visit never.com in a browser, it will get listed here, on the Unified tab : [image: 1742490733609-7d291f7a-cfb3-4a3c-8b3a-ea55b8a531a8-image.png] here it is : [image: 1742490719693-8eb442b1-0ffd-42d6-8bd6-aa53a2acef16-image.png] When I add "never.com" to the (a) "DNSBL Custom_List" it will be blocked and shown on the Alerts tab : [image: 1742491105178-4c6dd8ab-f6d7-4266-8da2-9e7c115f56f3-image.png] If nothings shows up no where, then you have to double check if your device is using pFsense, the resolver, as the DNS server. If the device you are testing is using some other DNS server, like 8.8.8.8 then the resolver and pfBlockerng will never see the DNS request, and pfBlockerng couldn't block the request.

@Bob-Dig thanks for the reply! Cool. I'll look into that. I have done some basic pfSense management, but am not as familiar with it as I would like to be. If you have any other suggestions, let me know! Thanks Dan

@inline6 Long ago the advice here was to start at 2 million if using pfBlocker. Ymmv

will do the tests! Thank you.

@antgalla Above, I though the YT (Youtube) list introduced your WAN IP. Now it's the Netflix list ? Btw : [image: 1741329069202-f1cc7fa5-e58d-4502-98d9-9293e29abe39-image.png] I'm not sure what this tells me : you get a list with IPv4 to block from netflix itself ( ) (and as soon as it is blocked, how could pfBlocker resolve and access https://www.netflix.com/... to get an update of this list ?) I've an idea : Knowing that pfBlockerng doesn't do anything when you've installed it. Knowing that your WAN IP isn't part of any list that you've not created yourself, I really presume you didn't add manually your WAN IP 'somewhere' in a file yourself to be used by pfSense. Get a backup (export) of the config of pfSense, open it with a text editor (Notepad++) and look where your WAN IP is mentioned - in a pfBlockerng section. That will give you the place in what part of the GUI it has been set.

@fmroeira86 Do what I do : use de "dev" version : the same as the non dev and probably less issues. True, I don't use pfSense 2.7.2 (can't afford it), so maybe both my pfBlockerng versions are different ? I see 0_16 for the non dev version and the devel version shows 3.2.1_22 for me. Btw : update frequency : I've set mine to "ones a week" as most lists don't update that often. After all, if every pfBlockerng and PI-hole and others update their lists every hours, the lists get hit so hard that the hosting comapny will bill the guy who makes the list, and it would become to expensive for a free service. When that happens, the lists tend to 'die'. Some good ones - some say the best - are already gone for this very reason. So : [image: 1741259182102-0ebfe713-d809-4569-8e39-1b5a3c8ab91c-image.png] is good enough for me.

@The-Party-of-Hell-No Well, this seemed to work! After the update, the error did not come back.

@johnpoz Same here. With out of the box pfSense resolver settings I can access it just fine. It's even native IPv6. DNSSEC : the entire DNSSEC chain is a indeed a mess, somewhat a proof that the site is legit : only a real 'gov' site can make such a mess out of it

@pftdm007 On what interfaces (WAN LAN Floating etc) did you place what rules ?

It has activated DNSLB, and reloaded after install and updated. In the CE version is there.

Yes, 1 Click. So we have a goog / perfect Solution. THX

@SteveITS said in Using the same whitelist in pfB and Snort: I'm not aware of hosts in Suricata_Trusted_Hosts being blocked so I assume it's working anyway...? That's the bottom line. If the hosts you do not want to get blocked are not getting blocked, then all is good. I don't recall specifically testing with nested aliases back when I wrote the new alias functionality into the custom blocking plugin. I was mainly going after FQDNs (fully qualified domain names) at the time. But the plugin is not digging into the alias to resolve it. It simply looks in the same pf tables that are listed under DIAGNOSTICS > TABLES. If the alias is there and is populated, then the plugin can test for IP addresses in the alias. If the alias is not listed under DIAGNOSTICS > TABLES, then Suricata is not using it even though it may show up in the View List dialog when viewing a Pass List. I built a sort of fail-safe error handling feature into the custom code so that it will silently ignore an alias that is not found during run time. The operating assumption there is the admin might have removed the alias and I didn't want the running Suricata process to abort if that happened.

There may be more to this than PFBLOCKERING/PFSENSE. Remember that browsers offer the ability to use DNS over HTTPS. Basically Firefox, Chrome, Edge... can use HTTPS to forward DNS requests straight out to the internet, not leaving it to your router to do. It's encrypted as well on port 443 so your router can't stop it. You have to go into the settings of the browsers you use and turn it off. Your DHCP settings can also be providing an internet DNS server IP to your computer's network settings so make sure that DHCP is providing your PFSense IP or the IP of your internal DNS server if you have one other than PFSense. I do, and have my DNS server forward to my PFSense box, which then takes over. In either of these cases, If DNS queries are direct from the browser to the internet, or to an internet DNS IP provided to the desktop via DHCP, PFSense/PFBlocker is 'out of the loop' at that point.

@CreationGuy https://docs.netgate.com/pfsense/en/latest/recipes/block-websites.html Use firewall rules seems to be the easiest for your situation.