iOS 14.01 kills pihole

The issue I am facing:
After upgrading to iOS 14.01 the iPhone kills all internet traffic (also for any other device in my network) a few seconds after conntecting to my router. One of the last logs i get from the pihole gui is So I wonder if anybody else is facing a similar problem? Since I'm unexperienced with pihole; were can I gather further errors/logs?

Details about my system:
Pihole v5.1.2, Raspberry Pi 3 Model B Plus Rev 1.3, dns routed via FritzBox 7590 with FritzOS 7.21

What I have changed since installing Pi-hole:
Upgraded iPhone to iOS 14.01 (before that, everything worked fine)

Thank you!

Muiltiple devices running latest IOS 14 and no problems.

Please generate a Pi-hole debug log, upload it when prompted and post the token here.

Here is the token:
Thank you!

Remark: I've disabled the pihole in my router config. If you need a debug log during the crash, let me know!

I'm on iOS 14.0.1 with no issue now that I fixed my /23 CIDR for conditional forwarding.

FWIW have you tried turning the randomized MAC (private address) off? It's under the specific wifi network (blue (i) next to the network name). I've had a few hinky issues and that seems to help... whether that's a truism or just coincidental, I couldn't say as I've got too low of a sample size to have an acceptable hypothesis.

Yes - I've turned off the private address feature already, without success. The basic problem is, that I do not get any errors indicating, that something is wrong. It's just based on the observation: connection iPhone to the WLAN >> freeze of Internet, pihole query logs stuck >> disabling pihole-dns-server in my router solves the problem or disconnecting iPhone and restart the router.
Maybe it has something todo with the setup of my FritzBox. On the other hand; the setup is quite standard and the router's OS is up to date...

I've created another debug token during the fail state:

Hi jfb,

have you had time to take a look at the debug logs? For me they seem ok - at least I didn't find any error, only a warning. That's the most frustrating with this issue: I don't find any direct error messages or a direct hint on what the problem is. At least it is 100% reprodruceable....
A workaround would be to exclude the iPhone from the pihole dns (not sure if this is possible), though.

Please generate a new debug token. Your old one expired after 48 hours.

here you go:

(I've generated the log during the failstate, again)

Your debug log shows your Pi-hole to have problems with its own IPv6 address:

*** [ DIAGNOSING ]: Networking
[✓] IPv6 address(es) bound to the eth0 interface:
   2a01:<redacted>:8a0c does not match the IP found in /etc/pihole/setupVars.conf
   fe80::<redacted>:3d34 does not match the IP found in /etc/pihole/setupVars.conf 

*** [ DIAGNOSING ]: Name resolution (IPv6) using a random blocked domain and a known ad-serving domain
[✓] is :: via localhost (::1)
[✗] Failed to resolve via Pi-hole (2a01:<redacted>:5f38)
[✓] is 2a00:1450:4001:821::200e via a remote, public DNS server (2001:4860:4860::8888)

This is because your public IPv6 prefix changed.
Consider to Use IPv6 ULA addresses for Pi-hole.

As iPhones (as almost all smartphones) would prefer IPv6 over IPv4, lack of a correct IPv6 address for Pi-hole may have contributed to your issue.

However, a change of your public IPv6 prefix (2000::/3 range) is triggered by your ISP (or a router restart, eventually) and would affect all of your network, not juts your iPhone.

Thank you! I have seen this, but didn't thought that this is the main issue. I've already set ULA as well as all IPv6 addresses (my eth0 strangely has 3). Ifconfig, as well as the pihole-webgui say, that the IPv6 is matching (at least) one of the IPv6 which I've set in the setupVars.conf. I've run pihole -g and even restarted the raspi. Still I got for all 3 addresses the error "does not match". Maybe this is connected to my issue? Any ideas why the the debug log complains about a correct IPv6 address?

Ah, careful now, please: I'm not sure it's the main issue, I just think it may contribute.

As said, your IPv6 calamities are caused by a change of your public IPv6 prefix.
That is nothing your iPhone nor any other device on your network could enforce, apart from your router.

It's definitely an issue you want to address, but there are no guarantees it will get your iPhone back to good behaviour.

Ok, let's have a look now. :wink:
Could you post a new debug token, please?

Thanks for the quick response!
Here the new token:
Still I've got all 3 addresses not matching :confused: even ifconfig doesn't tell me any different IPv6 addresses. I've further set my router to enforce ULA (before it was only preferred)
(remark: the debug token was generated without setting up the router using the pihole dns, let me know, if I should enable the pihole in my router again)

Did you manually edit setupVars.conf?
That file now contains multiple IPv6 addresses, where it normally would contain just one.

Limit that to at most one IPV6_ADDRESS entry.
I'd pick the ULA one (fd00::/8 range).

If you manually edit that file now, restarting Pi-hole's DNS service afterwards would probably suffice:

pihole restartdns

Ah - ok. Since the debug log said, it's ok to have multiple IPv6 as long as one is working I've set all 3 IPv6 addresses of eth0. I've followed your advise and kept the fd00.... only. After pihole restartdns the debug log doesn't complain anymore:

I'll try the new config tomorrow with the iPhone. So long - thank you again!

When this happens, how do the last lines of the Pi-hole log files look like?


tail -n 100 /var/log/pihole.log
tail -n 100 /var/log/pihole-FTL.log

Indeed - it seems that the problem is solved. At least the Pihole doesn't freeze shortly after the iPhone's connection. Looks good! I will see if it also works in the longterm. Summary:
So the source of the problem was the changed IPv6 address of my raspi. I've set the ULA to "enforced" (before it was somehow optional in the fritzbox router) and updated the IPv6 in the setupVars.conf and in the router's DNS settings, and restarted the pihole restartdns
What I still don't understand: Even if the iPhone doesn't like IPv4, how can the erroneous IPv6 cause the whole Pihole to freeze. I would expect, that the iPhone just doesn't have an Internet connection. And how is it connected to iOS 14.01 - before the update, it was working fine, even though the change of IPv6 could have happened at the same day by coincidence. Any other device didn't have a problem with that. Unfortunately, I was not able to find any direkt error in the pihole logs, which would have given a hint, what really the problem was...
Anyway - big thanks to everybody for your help!

Thanks for the tip. I only have had a look in the /var/log/pihole.log in the very beginning - that was always the also given in the pihole debug log (hourly). I didn't investigate the *FTL.log. Good to know, that there could be further infos, though!

It cannot - that's why I was cautious not to suggest that fixing your IPv6 prefix would solve your issue.

But since it seems it has:

It may well have been that, a mere coincidence.

When you claim that your Pi-hole froze, was that observation limited to your iPhone accessing Pi-hole's web UI?
Then it may indeed have been a problem related your iPhone's stubborn insistence of using Pi-hole's inoperational IPv6 address instead of its working IPv4, limited to your iPhone only. Or maybe iOS 14 introduced that increased level of stubbornness, and you never noticed your global IPv6 prefix changing before.

Anyway, glad it's solved for you. :slight_smile:

That's correct - it was merely based on the observation: As soon as the iPhone connected to the WLAN, all devices in my network were not able to access the internet anymore. The internal network communication was still working. Only a restart of the router solved the issue until the iPhone connected again. After some testing, I disabled the dns-routing over the pihole which solved the problem. I've had a look into the query logs of the web-gui of the pihole (since I didn't found any hint in /var/log). The query log stopped posting messages in the fail state - thus I derived, that the pihole's function must somehow stuck. Then I came to you :wink:
The pihole itself seem to work in this fail state - I could use the web-gui, the pihole commands, etc. It just didn't post any query log messages and seem to block the traffic for all other devices...

Yes - thank you again. It would have been a bit more satisfying to find out the root cause of the problem, though. But anyway: Don't look a gift horse in the mouth!