Safari browser no longer works - Blocking private Relay

michmoor

Greetings !

I have blocked Apple PrivateRelay service using pfblocker but I then noticed that my Safari browser no longer works. I get a message that states "Safari cant connect to iCloud Private Relay".
Doing some googling, I found comments that stated that the DNS reply should be NXDOMAIN. In the logs I see it being returned as SVRFAIL.

Is there anyway to get the response to be NXDOMAIN? 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). They both use 0.0.0.0 and they both log to the Alert tab. i believe.

michmoor

I then went into DNSBL Safesearch and selected all the DoH/DoT blocking list. Its enabled.
Not only does this not work it allowed PrivateRelay to work.

Sergei_Shablovsky

@michmoor said in Safari browser no longer works - Blocking private Relay:

I then went into DNSBL Safesearch and selected all the DoH/DoT blocking list. Its enabled.
Not only does this not work it allowed PrivateRelay to work.

Is that possible to post here all blocking list that You use?

Thanks!

michmoor

@Sergei_Shablovsky

Not entirely sure what youre asking for regarding block list used. If its the DoH/DoT screen you are responding too i ended up blocking all of those listed but still didn't work. To Apples credit Private Relay is very difficult to block on the network level without the apple devices becoming unusable if using Safari. The ultimate solution is to disable IPR on the account.

Gertjan

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

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.