@manval said in pfBlockerNG blocks Greek IPs from StarLink as IP located in North America:

I disabled cron in pfBlogerNG and it is still running !

The cron task handles also the max log file sizes :

8a399f8d-98e1-4e53-9c3b-1249432f5ceb-image.png

so, imho, if set to disabled, it will still keep care of these files by rotating them.
Not doing so will fill up the disk.

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

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

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 :

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.

What is the best OISD list to use as of right now on the latest non-deval build?

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