Pi-Hole Host is able to connect through IPv6, but the rest of the network can't

Expected Behaviour:

Any device in the network can connect through IPv6 to the internet

Actual Behaviour:

Hi, it seems my ISP has finally assigned me an IPv6 connection, and most of my devices have acquired IPv6 addresses within the last few weeks. I am able to see both their IPv4 & IPv6 IPs on the network management section (I use my Pi-Hole as the network's DHCP server), but for some reason, none of the connected devices are able to solve websites using IPv6.

I am able to run dig from within my Raspberry Pi 4 (running RPiOS arm64 beta) and solve IPv6 addresses both using Unbound and Cloudflared:

dig AAAA ipv6.google.com @ -p 5335

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> AAAA ipv6.google.com @ -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35213
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 1472
;ipv6.google.com.               IN      AAAA

ipv6.google.com.        26619   IN      CNAME   ipv6.l.google.com.
ipv6.l.google.com.      300     IN      AAAA    2607:f8b0:4012:800::200e

;; Query time: 3106 msec
;; WHEN: Thu Oct 01 16:42:50 CDT 2020
;; MSG SIZE  rcvd: 93
dig AAAA ipv6.google.com @ -p 5053

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> AAAA ipv6.google.com @ -p 5053
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7917
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 1232
;ipv6.google.com.               IN      AAAA

ipv6.google.com.        28      IN      CNAME   ipv6.l.google.com.
ipv6.l.google.com.      28      IN      AAAA    2607:f8b0:4000:802::200e

;; Query time: 67 msec
;; WHEN: Thu Oct 01 16:43:51 CDT 2020
;; MSG SIZE  rcvd: 135

Even after reconfiguring the installation using pihole -r and updating gravity with pihole -g after enabling IPv6 within Unbound, the results stay the same.

My Unbound config:

    # If no logfile is specified, syslog is used
    # logfile: "/var/log/unbound/unbound.log"
    verbosity: 0

    port: 5335
    do-ip4: yes
    do-udp: yes
    do-tcp: yes

    # May be set to yes if you have IPv6 connectivity
    do-ip6: yes

    # You want to leave this to no unless you have *native* IPv6. With 6to4 and
    # Terredo tunnels your web browser should favor IPv4 for the same reasons
    prefer-ip6: yes

    # Use this only when you downloaded the list of primary root servers!
    root-hints: "/var/lib/unbound/root.hints"

    # Trust glue only if it is within the server's authority
    harden-glue: yes

    # Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
    harden-dnssec-stripped: yes

    # Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes
    # see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details
    use-caps-for-id: no

    # Reduce EDNS reassembly buffer size.
    # Suggested by the unbound man page to reduce fragmentation reassembly problems
    edns-buffer-size: 1472

    # Perform prefetching of close to expired message cache entries
    # This only applies to domains that have been frequently queried
    prefetch: yes

    # One thread should be sufficient, can be increased on beefy machines. In reality for most users running on small networks or on a single machine, it should be unnecessary to seek performance enhancement by increasing num-threads above 1.
    num-threads: 1

    # Ensure kernel buffer is large enough to not lose messages in traffic spikes
    so-rcvbuf: 1m

    # Ensure privacy of local IP ranges
    private-address: fd00::/8
    private-address: fe80::/10

If there's anything else I might need to add, just ask.

Thanks for the help!

Debug Token:


Well, your dig results show DNS resolution works.
Could you show us what doesn't work, please?

Oh, minor detail there :sweat_smile:

When I perform a test using Internet.nl, I'm not able to pass any of the IPv6 tests using a Windows 10 Pro 2004 laptop.

Using Ubuntu WSL2 on the same device leads to the same results when performing the same dig:

; <<>> DiG 9.16.1-Ubuntu <<>> AAAA ipv6.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42079
;; flags: qr rd ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;ipv6.google.com.               IN      AAAA

ipv6.google.com.        0       IN      CNAME   ipv6.l.google.com.
ipv6.l.google.com.      0       IN      AAAA    2607:f8b0:4012:80a::200e

;; Query time: 110 msec
;; WHEN: Thu Oct 01 17:49:32 CDT 2020
;; MSG SIZE  rcvd: 124

And performing a ping from within PowerShell Core leads to a timeout:

 ping ipv6.google.com

Pinging ipv6.l.google.com [2607:f8b0:4012:80a::200e] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 2607:f8b0:4012:80a::200e:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

The network adapter has its own IPv6 address, and as you said DNS resolution works as expected, but no websites are able to be opened for some odd reason.

Wireless LAN adapter WiFi AX1650:

Connection-specific DNS Suffix . : lan
Description . . . . . . . . . . . : Killer(R) Wi-Fi 6 AX1650x 160MHz Wireless Network Adapter (200NGW)
Physical Address. . . . . . . . . : AA-BB-CC-DD-EE-FF
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv6 Address. . . . . . . . . . . : 2806:xxxx:xx:xxxx::yyyy(Preferred)
Lease Obtained. . . . . . . . . . : Wednesday, September 30, 2020 11:36:24 PM
Lease Expires . . . . . . . . . . : Friday, October 2, 2020 10:37:31 AM
Link-local IPv6 Address . . . . . : fe80::xxxx:xx75:xxxx:xxxx%28(Preferred)
IPv4 Address. . . . . . . . . . . :
Subnet Mask . . . . . . . . . . . :
Lease Obtained. . . . . . . . . . : Wednesday, September 30, 2020 10:36:15 PM
Lease Expires . . . . . . . . . . : Friday, October 2, 2020 9:16:53 AM
Default Gateway . . . . . . . . . : xxxx::xxxx:xxxx:xxxx:xxxx%28
DHCP Server . . . . . . . . . . . :
DHCPv6 IAID . . . . . . . . . . . : 00000000
DHCPv6 Client DUID. . . . . . . . : 00-00-00-00-00-00-00-00-00-00-00-00-00-00
DNS Servers . . . . . . . . . . . : xxxx:xxxx:xx:xxxx::1
NetBIOS over Tcpip. . . . . . . . : Enabled

Using the same test on an Android device reports that the connectivity of the IPv6 DNS resolver works correctly, but none of the other v6 tests do.

And trying to open an IPv6 website using Google Chrome on both the Android and Windows devices return DNS_PROBE_FINISHED_NXDOMAIN.

The router I'm using is an ASUS GT-AX11000 on firmware, IPv6 is native with a Stateful configuration, only the RPi's IP as the DNS servers, and Router Advertisement enabled.

Thanks for the help!

Is this preventing any of your apps or software from working?

Connectivity of a client via ipv6 is independent of Pi-hole.

Yes, to a degree.

It doesn't always happen, but randomly media resources like photos or videos (think YouTube thumbnails, imgur links, Gfycat, etc.) will take really long times to load or outright bounce into a timeout.

Given I'm using Pi-hole as a DHCP server, I thought that perhaps it would be a good place to look first, since it's the only piece of networking equipment I own that might fall outside of a common residential setup.

If solving this would be more closely related to either Unbound or the router itself, I'll now know at least where to look more closely.

This sounds like an IPv6 problem on the Windows client.

Even though the same problems also happen on the Android client?

To make it weirder, opening a browser on the RPi itself can't connect to an IPv6 website, even though DNS works as expected.

I don't think it's a DNS issue.

Your DNS is shown to be working on your Windows device as well, as demonstrated by your successful dig.

Also, if DNS wouldn't work, you'd see a Name not known or similar with ping. Your ping reads:

Your DNS resolution for your ping is fine - it's contacting the IP address that fails after DNS resolution returned an IPv6 address.

You should take a closer look at your router for proper IPv6 configuration.

Okay, just got off the phone with my ISP.

Turns out they don't know how I got a connection in the first place :woozy_face:.

According to them, no client of them within the country has IPv6 enabled on residential connections, and they advised me to simply ignore it, so at this point I'm just plain confused.
Clearly something is connected, given I'm able to perform digs, but at least now I know it's an ISP problem and not a Pi-Hole problem.

Anyway, thanks for the help everyone! Looks like disabling IPv6 within my router will be an easier fix for the moment.

Okay, it seems there has been an interesting update!

After I tried looking around on the DE within the Pi, I was able to both enable IPv6 connectivity for the Ethernet NIC and successfully complete both a test and perform navigation using IPv6 only. This got me thinking that perhaps the problem was within one of my other devices, so after digging around my laptop's settings and setting a v6 address, subnet mask, gateway and the Pi's IP as DNS manually, I was also able to successfully perform both previously mentioned tasks on the laptop.

When I returned everything to the defaults, and then rebooted, only dig continued working on the device, and I was back to square one.

As far as the details tab goes, it seems that the only missing parameter is the DHCPv6 gateway, so given that I'm using Pi-Hole's built in DNS server in place of my router's, I was wondering which setting I should modify to begin broadcasting a v6 gateway to the network's devices as well.

I'll go ahead and link to the results of the tests performed for good measure.

Pi-Hole's ping after DE fix:

PING ipv6.google.com(qro02s15-in-x0e.1e100.net (2607:f8b0:4012:80b::200e)) 56 data bytes
64 bytes from qro02s15-in-x0e.1e100.net (2607:f8b0:4012:80b::200e): icmp_seq=1 ttl=119 time=28.3 ms
64 bytes from qro02s15-in-x0e.1e100.net (2607:f8b0:4012:80b::200e): icmp_seq=2 ttl=119 time=11.6 ms
64 bytes from qro02s15-in-x0e.1e100.net (2607:f8b0:4012:80b::200e): icmp_seq=3 ttl=119 time=10.5 ms
64 bytes from qro02s15-in-x0e.1e100.net (2607:f8b0:4012:80b::200e): icmp_seq=4 ttl=119 time=10.2 ms
64 bytes from qro02s15-in-x0e.1e100.net (2607:f8b0:4012:80b::200e): icmp_seq=5 ttl=119 time=12.10 ms
64 bytes from qro02s15-in-x0e.1e100.net (2607:f8b0:4012:80b::200e): icmp_seq=6 ttl=119 time=12.7 ms
64 bytes from qro02s15-in-x0e.1e100.net (2607:f8b0:4012:80b::200e): icmp_seq=7 ttl=119 time=12.3 ms
--- ipv6.google.com ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 11ms
rtt min/avg/max/mdev = 10.238/14.099/28.348/5.897 ms

Laptop's results before manually setting the gateway
And after assigning the gateway

Router advertisement is already enabled within both my router and Pi-Hole's DHCP settings, but I'm not sure why neither of them are able to broadcast their address to the devices.

What are you referring to by DE?

And how does your sudden IPv6 connectivity match with your earlier conclusion of IPv6 not being available at all?

IPv6 doesn't need gateways, public IPv6 addresses are routable by design.
Also, your devices may not use DHCPv6 at all (neither stateful nor stateless) to join your network.

You may want to familiarise yourself with IPv6 before enabling it.

If you indeed face a new issue, please consider to open a new topic.

I meant Desktop Environment, as the Raspberry Pi I use as a Pi-Hole is connected to a display running PIXEL. Last time after I had multiple issues trying to connect through IPv6 unless performing a DNS lookup through dig I concluded that perhaps there was some misconfiguration on my ISP's side of the equation, and that me being assigned a valid IPv6 address would have been at best a work in progress, with no ETA as to when it would be practical to use.

As you quoted, I stated that according to them I wasn't supposed to be able to connect through the v6 protocol at all, I wouldn't have looked into it more if I didn't have a suspicion that perhaps the person I spoke to hadn't been briefed and/or trained about a case like mine, which led to me asking for help here.

That's correct, and also one of the main reasons I was waiting for support to become available actually. What I meant by gateway was based on the settings I had to change within the adapter settings to be able to connect in the first place.

What I did was go here:

And input the currently assigned IPv6 address, leave /64 as per default, and in "Default Gateway" I entered

the underlined address that I got from my ISP through the router.

Doing so led me to be able to browse successfully, but only on the laptop that I performed these steps in.

What makes me believe that this is doable is that before I was assigned a native connection, I was able to use Hurricane Electric as a tunnel and browse through IPv6 with it enabled (most of the other devices I've been referring to are Android-based, plus I'm able to both see they too have been assigned valid v6 addresses and that they are indeed reported within the Network section of Pi-Hole's Admin page.

You may be right in that I might need to familiarize myself more with the concept, which is why I've been adamant on getting this to work and learn in the process; I wouldn't have asked for help if I wasn't stumped, and this seemed like the most reliable place to look for help given the setup I'm using.

If you consider that what I previously stated constitutes a different issue altogether in spite of what I just wrote, I'd be glad to move over the irrelevant pieces of my troubleshooting to a new topic, though I think that given both statements are related to the same chain of events, it would be easier to follow through the taken steps if they are contained within the same thread.

In any case, I hope that I can still request your help, and I'd like to thank you in advance for your guidance.

It seems your ISP's claims are correct:
There is no public IPv6 address (2000::/3 range) on that ppp0 interface.

There is only a link-local (fe80::/10 range) and a ULA address (fd00::/8 range, normally!).
In your case, that ULA address is from the fc00::/8 range, which is currently undefined by IETF.

With IPv6, devices won't commonly request to be assigned an IP address via stateful DHCPv6.
Instead, a device will calculate IPv6 addresses for its interfaces by itself.
You could well oberserve link-local and ULA addresses in Pi-hole's Query Log even without public IPv6 connectivity.

Again, you're right. The thing is that all compatible devices have a public facing address that I'm able to ping from outside the network, but the devices themselves are not currently able to navigate through the v6 protocol.

Both the router and PiHole's query log are able to display the v4 and v6 addresses including both link local and public facing.

As far as I can tell the issue is related to something in my network not correctly advertising all of the parameters required to establish a successful connection automatically, otherwise I wouldn't have been able to take the screenshots I just took. (If you'd like to see for yourself, just tell me where can I send you the complete address and you can try to ping it.)
At the moment, only the Pi and the laptop I'm using are able to navigate successfully using the native connection, even if outside of standards as you mention, I'm able to see that something happens that allows these two to work and the rest still don't. If nothing else, I'd like to know how the exception came to happen so I can look on my own what led to it in the first place.

It's only the fc00:: address on your ppp0 adpater that's unusual. Your link-locals and publics look ok.

The information you have provided about your network so far, including your ISP's statement, is both inconclusive and contradictory with regards to IPv6. The issue may be with your devices, your router, your ISP or your previous tunnel broker connection, or any combination.

Your Pi-hole is neiter introducing IPv6 issues, nor does it seem it is affected by them in the same way as the rest of your network.

Your best bet for support may be to search your ISP's and router's forums for related issues.

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.