I think pfSense has bugs. I uninstall pfBlockerNG and install the pfBlockerNG-devel and I still have the same problems.
Furthermore, I add manually list to permit the specific IPs of starlink...
49526da4-6011-45e1-85ef-53b9af36df86-image.png
.... the rules are in the top of list in Floating rules but pfSense ignore it
58af0305-9903-43cd-961b-a7abe09591b2-image.png
d93b1fca-8743-43af-8ce6-c3d78cdb973e-image.png

I added manually the specific IPs in floating rules. Tomorrow, I will check if this tricks works.
fdc341b3-36f9-4638-bd37-f10ac905b1e7-image.png

Also, I disabled cron in pfBlogerNG and it is still running ! How to fix this bug?
8ac5d95d-17bb-4515-9b2e-31bbb9f53b0b-image.png
92a41c31-b461-4a70-aec7-689e40c891da-image.png

We are suspecting more and more that we are hitting #1 in this thread.
Since 24.11 and adding more threat lists we are now up from ~200000 to ~500000 ips being blocked and are having trouble with one or both 6100MAX randomly freezing during pfblockerng updates. It can take from 1-14 days before it happens (most often 1-7 days) and four out of five times it is the secondary firewall in our HA setup that freezes but we have also seen the primary freeze and backup takes over and today both (!) firewalls froze during the update for the first time (blue led on and no blink on both).

"A communications error occurred while attempting XMLRPC sync." is the usual symptom.
pfBlockerNG 3.2.0_16

Disabling CIDR aggregation did not help.
We have now disabled syncing in pfblockerng and moved the secondary firewalls cron updates to 15 min after primary firewall so they don't do the updates at the same time to see if it solves this issue.
Can someone please look at these critical issues? If we can't use pfblockerng (or load threat lists in the rules directly like opnsense does it ) we can't use pfsense.

@Yamka said in Static and Dynamic IPs Pass rules:

My main struggle is allowing WhatsApp (for example) traffic through my firewall

Why is it blocked in the first place?

@Gertjan said in I don't receive emails ONLY on Apple devices:

The famous white 1x1 pixel image present in a mail ... I know.

That issue has been solved many years ago

Not the infamous 1 pixel image used on websites. This is usually general, required content. Real images, present in almost all commercial messages, without which the email does not render properly. Like the name of the sender as an image, signature lines, etc. You probably see dozens per day without noticing. Install something like Little Snitch if you want to see what's all going on behind the scenes.

@Gertjan Oh yeah that's true, my bad, I changed it and the bank app and logging continue to work fine, thank you again.

ce2b5791-5f31-42ce-8817-17cf642daedc-image.png

c33ea8e5-60e0-4ed8-985b-7b898abaf545-image.png

@Gertjan
No worries. Thanks again

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 :

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 :

57b628ad-ba2c-4d34-9b0b-777ae5ee91f4-image.png

and I visit never.com in a browser, it will get listed here, on the Unified tab :

7d291f7a-cfb3-4a3c-8b3a-ea55b8a531a8-image.png

here it is :

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 :
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.

Makes sense. Thanks