Pi-hole selecting different primary ipv4 address

New to Pi-hole but have gone through a number of help topics searching for a solution or performing additional troubleshooting. I have a Raspberry Pi Zero 2 W running Pi-hole (version 6). The Rpi device has a static IP address assigned for the wlan0 interface (and its associated network connection).

The network has multiple VLANs, and this device has the vlan package installed and avahi daemon running to help streaming to devices across the VLANs (streaming devices are separate from personal devices). Essentially this Rpi is acting as a relay for streaming.

As a result multiple network connections are established on the Rpi device.

wirelessconnection1 wlan0
wiredconnection1 eth0
vlan50 eth0.50
vlan60 eth0.60

Pi-hole is not the dhcp server.

Expected Behaviour:

Pi-hole should use the ip address of the connection (wirelessconnection1) and interface wlan0 and should show this on the System page (Primary ipv4 address and interface).

Actual Behaviour:

If eth0.50 and eth0.60 are up, then Pi-hole is not using the ip address of the wirelessconnection1 (wlan0). The System page shows the ip address of eth0.50 as the Primary ipv4 address.

If eth0.50 and eth0.60 are down (nmcli con down vlan50 and nmcli con down vlan60) the web gui (admin page) for Pi-hole shows the correct ip address and interface on the System page. Behavior is as expected.

In summary: it appears that Pi-hole is not binding (sorry if that is not the correct term) to the correct IP address of wlan0. The .toml file does not seem to have this setting (or I simply cannot find it)? Also, is there a pihole -r with reconfigure in v6? There are many posts that specify a reconfigure may be in order, but I see no way to actually trigger "reconfigure" in v6.

Thanks in advance for any insight.

As requested by our help template, 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 if you run your Pi-hole as a Docker container:

docker exec -it <pihole-container-name-or-id> pihole -d

where you substitute <pihole-container-name-or-id> as required.

Apologies. Here are tokens for two files. 1) with VLAN50 and VLAN60 down. 2) with them up (which exhibits the primary ip address problem).

  1. https://tricorder.pi-hole.net/ryxmGuga/

  2. https://tricorder.pi-hole.net/dcYu4Db1/

The related options are dns.interface to set the interface as shown in Pi-hole's Interface settings UI, and dns.listeningMode to switch between its different listening modes.
Above notation means you can find those options in pihole.toml in the [dns] section, e.g.

   [dns]
     (…)
     interface = "wlan0" ### CHANGED, default = ""
     (…)
     listeningMode = "SINGLE" ### CHANGED, default = "LOCAL"

Note that pihole-FTL would bind to the wildcard address by default, i.e. it is listening on all interfaces, discarding requests from interfaces that it is not configured for.

You have configured your Pi-hole's Interface settings to Respond only on interface wlan0.

Your debug log shows that this has been correctly applied by the respective pihole-FTL/dnsmasq option:

*** [ DIAGNOSING ]: contents of /etc/pihole

-rw-r----- 1 pihole pihole 5.1K Mar 25 21:57 /etc/pihole/dnsmasq.conf
   (…)
   interface=wlan0

Furthermore, both your debug logs show that Pi-hole is only answering requests via wlan0:

*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✓] www.btc-xp.com is NOERROR on lo (127.0.0.1)
[✓] No IPv4 address available on eth0
[✓] www.btc-xp.com is NOERROR on wlan0 (192.168.10.12)
[✓] doubleclick.com is 142.250.72.174 via a remote, public DNS server (8.8.8.8)

*** [ DIAGNOSING ]: Name resolution (IPv6) using a random blocked domain and a known ad-serving domain
[✓] pawblemsolver.com is NOERROR on lo (::1)
[✗] Failed to resolve pawblemsolver.com on eth0 (fe80::<redacted>25%eth0)
[✓] pawblemsolver.com is NOERROR on wlan0 (fe80::<redacted>2a%wlan0)
[✗] Failed to resolve doubleclick.com via a remote, public DNS server (2001:4860:4860::8888)
*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✓] pl-redirect927.cfd is NOERROR on lo (127.0.0.1)
[✓] No IPv4 address available on eth0
[✓] pl-redirect927.cfd is NOERROR on wlan0 (192.168.10.12)
[✗] Failed to resolve pl-redirect927.cfd on eth0.50 (192.168.50.15)
[✗] Failed to resolve pl-redirect927.cfd on eth0.60 (192.168.60.15)
[✓] doubleclick.com is 142.250.72.174 via a remote, public DNS server (8.8.8.8)

*** [ DIAGNOSING ]: Name resolution (IPv6) using a random blocked domain and a known ad-serving domain
[✓] metplnat.metplxx.com is NOERROR on lo (::1)
[✗] Failed to resolve metplnat.metplxx.com on eth0 (fe80::<redacted>25%eth0)
[✓] metplnat.metplxx.com is NOERROR on wlan0 (fe80::<redacted>2a%wlan0)
[✗] Failed to resolve metplnat.metplxx.com on eth0.50 (fe80::<redacted>25%eth0.50)
[✗] Failed to resolve metplnat.metplxx.com on eth0.60 (fe80::<redacted>25%eth0.60)
[✗] Failed to resolve doubleclick.com via a remote, public DNS server (2001:4860:4860::8888)

This would suggest that your observation is only a glitch in Pi-hole's UI.

To see if that glitch would also affect the other interface specific option, could you try changing your Interface settings to Bind only to interface wlan0, to see if that would impact Pi-hole's Primary IP addresses as shown on its Settings | System Settings?

Using that Bind only… option would have pihole-FTL really binding to the configured interface, instead of using the default wildcard method.
Typically, this would only be required if you'd run another DNS server for a separate interface on port 53 of the same machine.

Here is an updated debug file token and a couple of screenshots after the change.

It does appear to only be an issue with what is shown in the web gui. I was seeing some errors in the logs, but those were likely due to something else (not related to P-hole). Thanks for the assistance!

https://tricorder.pi-hole.net/DoXmY7Yu/

@rdwebdesign, how are Primary IP addresses as shown on Settings | System Settings determined?
They are unexpectedly showing an eth0 IP even when Pi-hole has been configured to listen or even bind wlan0 only.

This is info is generated by FTL and sent to the web interface.

This is returned by /api/network/gateway endpoint and this is generated by these 2 functions: FTL/src/api/network.c at b7eb53bf32ab76546db87c6db6d7085526788d67 · pi-hole/FTL · GitHub

I think this is the same information used in Tools > Interfaces page.

As a follow-up to the issue of the incorrect primary IP4 address showing in the pi-hole web gui, the issue was related to the routing priority on the device running Pi-hole. The priority appears to play a role in what is shown in the web gui under Settings | System Settings (which makes sense, I think). Note that the priority does not appear to impact Pi-hole functionality if other settings are correct. In my case, only the routing priority needed to be adjusted using a simple set of nmcli commands (lower number = higher priority)

nmcli connection modify <the connection that should have priority> ipv4.route-metric 50
nmcli connection modify <a connection that should have a lower priority> ipv4.route-metric 400
nmcli connection modify <a connection that should have a lower priority> ipv4.route-metric 401

I believe my question is resolved. Thanks for the assistance.

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