Router Advertisements advertising old PiHole server ipv6 address

Help Community Help
1

I recently installed a new pihole server on new hardware. I used teleporter to transfer the configuration from my old pihole server to the new one. Everything seems to be working, so I turned off the old pihole. Except it seems that clients are still using the old ipv6 address for ipv6 resolution. My router does not advertise the pihole address - it doesn't allow this to be configured. The clients are picking up the old address from somewhere.

I vaguely remember configuring my old pihole server to advertise itself, and I suspect that the address has been carried across with teleporter and it is now being advertised by the new pihole server, instead of its own address. The only place I found a reference to the old address in the teleporter file is in setupVars.conf in the IPV6_ADDRESS variable. However, this is not replicated in the new pihole server's setupVars.conf - that does not have the IPV6_ADDRESS variable set.

Is it possible that on importing the teleporter file, the process wrote the value from setupVars.conf elsewhere?

2

Do you have any checkboxes filled in the Settings > DHCP > Advanced DHCP settings?

image
image1105×472 34.3 KB

3

Those are no longer ticked on the old PiHole server. I needed to enable DHCP in order to untick them, then disable DHCP again. I had assumed that the tick boxes wouldn't matter if DHCP was disabled, particularly since they can't be changed if DHCP is not enabled. After making this change, the address is still being assigned to clients on the network after reboots and clearing the IP stack in Windows.

Thiose boxes are ticked on the new PiHole server which has taken over DHCP duties.

4

How do you know that's the IPv6 of your turned off Pi-hole?
How do you know that clients are using that IPv6 address?

To that end, please run the following command on a client and share the output of

nslookup flurry.com

Also, please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:

pihole -d

or do it through the Web interface:

Tools > Generate Debug Log

5

How do you know that's the IPv6 of your turned off Pi-hole?

Because it is the same as the output of ip a and when I go to the IPv6 in a browser, it goes to the old PiHole's web interface. That is the address listed as the ipv6 DNS resolver in the output of ipconfig /all

If that old PiHole is turned off, DNS resolution stops working for the affected clients.

I'll share the debug token when I am back home.

6

Debug log from OLD PiHole: https://tricorder.pi-hole.net/foz0FC3U/

Debug log from NEW PiHole: https://tricorder.pi-hole.net/JJuFqQrK/

7

Could you please also provide:

8 
nslookup flurry.com
Server:  pi.hole
Address:  fe80::<redacted>8c

Name:    flurry.com
Addresses:  ::
          0.0.0.0

This is with the old pihole turned on. Its the one getting the requests for ipv6. With the old pihole turned off, and rebooting the client, nslookup still tries to go to that address, even though the new pihole should be announcing its address and clients using that.

nslookup flurry.com
DNS request timed out.
    timeout was 2 seconds.
Server:  UnKnown
Address:  fe80::ba27:ebff:fe7e:c98c

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Request to UnKnown timed-out

That is why I wondered if the new pihole was announcing the old address due to teleporter copying some setting across.

9

What client was that nslookup run from?

That client is indeed using your old Pi-hole's link local address (range fe80::10).

In contrast, enabling Pi-hole's IPv6 support via Settings|DHCP would configure Pi-hole to propagate its global GUA address as DNS server.
The respective line is also present in your current RPi's debug log:

dhcp-option=option6:dns-server,[::]

where

[::] means "the global address of the machine running dnsmasq"

(quoting dnsmasq's documentation)

This raises the question how your client has been told to use your old Pi-hole's LLA as DNS server.

With IPv6, it is a router's job to advertise network configuration details, including local DNS server addresses, so the router would be the prime suspect here.
But perhaps you did manually configure an IPv6 DNS server address, at least for that client?

As you state that your router does not expose any IPv6 configuration options, you may try to snoop into your network's Router Advertisements, e.g. via radvdump:

sudo apt install radvdump

Then just run

sudo radvdump

and wait for a while looking at a blank screen until the RAs fill your screen (that may take a few minutes). Then press Ctrl+C to exit, and share the output here.

10

I've been running Wireshark to look for Router Advertisments (icmpv6.type == 134 is the filter for that). I do see messages from my router giving prefix information but no RDNSS. Every 5 minutes or so I see a Router Advertisment from the new PiHole server, which does include RDNSS with the Global address for itself - i.e. the IPv6 address that clients should be using now as their IPv6 DNS server.

For some reason my laptop was not acting on these RA messages. I did some searching and it seems there is a longstanding bug in Windows that it ignores RDNSS if both IPv4 and IPv6 are enabled. I'm not ready to go completely IPv6 (given these issues I am wondering why I spend any hours of my life trying IPv6 at all!)

I am able to use Set-DnsClientServerAddress to manually set Windows to use the correct address for the new server. However, when I then reset the settings with Set-DnsClientServerAddress "WiFi" -ResetServerAddress the old pihole address is back.

Since I am not seeing any IPV6 RA traffic with the old address, then I guess I am wrong about the new PiHole server telling my client to use the wrong address, and it is getting added by some other setting or process, perhaps only fpr my laptop. Troubleshooting DNS and IPv6 isn't really feasible on Android, so I'll need to get hold of another computer to see if I can repeat the issue elsewhere.

Update for anyone having similar issues: Running netsh winsock reset and rebooting my Windows PCs seems to have shaken using the routers address for DNS resolution. After doing this, the PCs use the RDNSS settings from Router Advertisments as expected. Before doing this, Windows seemed to be ignoring what was in the RAs.

Another update after much troubleshooting I found that my router is responding to DHCPv6 requests with its own address as a DNS server, so even when the PiHole is correctly sending out its own address in Router Advertisments and DHCPv6 packets the address assigned by DHCPv6 from my router is being preferred if its packets are being received first. The key to figuring this out was the following Wireshark filter:

icmpv6.opt.rdnss || dhcpv6.option.type == 23

This displays all the IPv6 network traffic that could be used to configure DNS automatically. The DHCP packets only appear if a client makes a DHCPv6 request.

Unfortunately my router doesn't have a switch to turn off DHCPv6 or tell it what DNS server to announce. Pretty annoying as I now have a DHCP race on my network resulting in inconsistency in what will be used for DNS resolution. I might be able to fix this by connecting my PiHole to my switch rather than the router, so it might be able to respond quicker - if that doesn't work I need to get a new router, or turn off IPv6.

11

You wouldn't have IPv6 only clients in your network, would you?

As long as there would be no alternate IPv6 DNS server address available for your clients, there would be no harm in disabling Pi-hole's IPv6 support.

As DNS will deliver the same answers (regardless whether they were requested via IPv4 or IPv6), your IPv4 and dual stack clients can send A as well as AAAA queries to your Pi-hole's IPv4 and still talk to their targets via IPv4 or IPv6 as they prefer.

12

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