Could be a misunderstanding then:
Your answer is referring yubiuser's post.
Yes, because his statement was "plain wrong", to say it in your words...
It says in the apple document
“ Avoid causing DNS resolution timeouts or silently dropping IP packets sent to the Private Relay server, as this can lead to delays on client devices.”
And
“The fastest and most reliable way to alert users is to return either a "no error no answer" response or an NXDOMAIN response from your network’s DNS resolver”
Per apple documentation.
Im not actually clear what is meant by this to be honest in light of a potential difference noted above. It’s confusing.
Ah, I see - you weren't pitching Pi-hole's implementation against Apple's specifications then, but rather pallebone's explicit blocking approach against Pi-hole's BLOCK_ICLOUD_PR. My apologies, that was of course my misunderstanding then.
1 Like
The underlying problem here is that Pi-Hole enables 'Apple Private Relay circumvention' by default, without the people installing Pi-hole being aware of this, since they have not enabled this feature themselves.
It also inadvertently exposes the public ip address of all PR users when they switch to such a wifi network using Pi-Hole.
A mistake, in my opinion; this should only happen when you specifically opt-in. And Pi-Hole 'admins' would also be aware of what is happening when issues like these happen.
Let’s please keep in mind that the Devs of Pi-Hole are doing this voluntarily and they aren’t getting a single cent for that.
Besides they are doing a tremendous job, usually way better than what is delivered by so called top global players.
Last but not least this feature / behavior had been announced:
https://discourse.pi-hole.net/t/pi-hole-ftl-v5-10-1-web-v5-7-and-core-v5-5-released/50009
Wishing you all a wonderful day…
| notDavid
June 2 |
- | - |
[quote="notDavid, post:50, topic:55516, full:true"]
The underlying problem here is that Pi-Hole enables 'Apple Private Relay circumvention' by default , without the people installing Pi-hole being aware of this, since they have not enabled this feature themselves.
It also inadvertently exposes the public ip address of all PR users when they switch to such a wifi network using Pi-Hole.
A mistake, in my opinion; this should only happen when you specifically opt-in. And Pi-Hole 'admins' would also be aware of what is happening when issues like these happen.
[/quote]
2 Likes
Any nefarious network can cause PR not to be used as its apples spec that the local dns server can disable it and the nefarious network can also redirect dns requests to a location of its choosing. That feature is by design from apple. If exposing your ip is a risk then any network you connect to should be assumed risky and you should only connect to networks you control and have tested the feature works, or a vpn with killswitch would have to be strictly enabled that does not use any dns to establish a connection. For these reasons I dont believe pihole choosing a default option to try block something is a problem. If you connect to a network its on you to test the network is safe or take arrangements before connecting to ensure your safety as anyone in charge of a network can disable apples PR at will with or without pihole involvement in my humble opinion. Not hating on anyone just pointing that out. Apple could include an option ‘block all internet traffic if PR cannot be used’ if that was a requested requirement from users of apple products.
1 Like
The Apple OS throws a warning when it is unable to use Private Relay.
Comment edited to reply to correct comment
2 Likes
Somehow replying via mail results in misleading formatting (at least it did for me).
The respective statements were made by @notDavid - not me.... (just to be precise)
Tried to fix that in my previous post but didnt manage to either.. sorry...
I might have found a way to break this semi reproducibly.
I think apple have made a change where the dns entries to check if limit ip address tracking aka a form of PR are cached and not rechecked on a network change.
Way I tested this is disabling cellular data by turning on airplane mode but then enabling wifi so only wifi could be used and turning off and on the phone.
Since only wifi is available it now checks the dns from pihole and finds PR cant be used so it does not use it and sites load normally.
However if you do the reverse (ie disable wifi or walk away from your ap far enough and reboot the phone) then when it connects on cellular (make sure you disable any vpns) it can access the dns for PR. The websites load at this point via apples PR option however if you then connect back to wifi it assumes that PR should still work as it already did the check for it and now on wifi sites wont load. To fix you repeat the airplane mode, reboot, make sure wifi only and sites load then it has done the check and disables PR and you can enable cellular again.
However it can happen that after some time it manages to check for PR availability on cellular then the entire process is cached again and you have to repeat.
Would be great if someone else can check this. I was able to reliably break or unbreak via pihole by doing this.
Apologies. I have corrected my comment reply.
Reason I am asking someone else to check is it might be an unintentional bug in the new IOS in which case might be possible to get apple to fix it.
It would have to be iOS and MacOS. Not impossible but probably less likely.
I’ve been reading this thread with quite some interest so I experimented a little with my iDevices. There are actually two settings that affect the use of PR. One is the one under wifi that’s been discussed here but there is also another setting under Settings->yourname->iCloud. If that one is set to on and hide my IP is on and pihole is in default config then I get a popup telling me the network can’t do PR and I should turn PR off. If I do the wifi hide IP is turned off and everything seems to work fine.
If instead the iCloud setting is off, which is my standard setting, and hide IP is on and default pihole I do not get the popup and Safari hangs.
This is definitely new and looks like a Safari bug to me.
2 Likes
Just jumping in to give another vote for jostrasser's solution (adding BLOCK_ICLOUD_PR=false to the FTL configuration file). Also, you don't need to reboot after; just run 'pihole restartdns' which triggers a read of that file. That fixed both the Safari hangs AND the email image loading for me and my wife. My settings are Apple's default: Private Relay OFF and Limit IP Address Tracking ON.
FWIW, I'd actually vote for having this be the default even if Apple fixes what must be a bug (or at a minimum undocumented behavior). Pihole does nothing to block traditional VPNs (or, for that matter, people who hop into their WiFi configuration and specify a custom DNS server), and it seems inconsistent to me to block just one specific type of VPN. I get the argument the other way, too, though, that it's not so much "blocking" as "advising" a client---just my two cents.
Love this project and what you guys have built. Can't believe there are only three of you. I donated!
1 Like
I haven't attempted it yet, but I suspect a workaround for iPhones can be achieved with their "Shortcuts" app.
At home, I have PR/Hide IP Address "OFF" (I'm behind my PiHole + VPN). Upon a network change (ie have left home and am on cellular/some other wifi), script set to automatically toggle PR/Hide IP address "ON".
Edit: Hmm, so far, closest I can get is a shortcut to get to the actual System Pref. portion of where PR exists. Anyone with more experience with this app, feel free to chime in! In the meantime, I will just have to stick to network-based VPN toggling.
I am reading through this thread and am having a hard time determining what the best solution for my home network is. Is it to disable "Limit IP Address Tracking" per iOS/MacOS device or to change BLOCK_ICLOUD_PR=false in pihole-FTL.conf on the pi-hole server? What are the pros/cons of each aside from one being per device and the other network wide?
Turning off blocking for the iCloud Relay did not work for my wife's phone, but turning off "Limit IP Address tracking" did work. Others might have needed to do both, or just the iCloud Relay.
Confirmed. Turning off “limit IP address tracking” worked for both iPhones and one Mac on our network.
1 Like
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.