Please follow the below template, it will help us to help you!
If you are Experiencing issues with a Pi-hole install that has non-standard elements (e.g you are using nginx instead of lighttpd, or there is some other aspect of your install that is customised) - please use the Community Help category.
Expected Behaviour:
Run: 'pihole reconfigure' and reset static ip address
Actual Behaviour:
Cannot successfully change static IP seemingly because I'm changing to a different subnet.
Debug Token:
Did not get a debug token. Could not solve host: tricorder.pi-hole.net.
I had pihole running on a rpi 5 and all was well until I decided to change the subnet it was sitting within. I installed it on the subnet 172.16.1.o/24 with the IP 172.16.1.17 and decided to move it to 192.168.0.0/24 with IP 192.168.0.117 . I followed serveral examples, at least on of which was on this site. But none of them worked. The Initial issue is that each of the example lists itself as changing/reseting the 'static IP address' and all of them are simply changing the client number within the same subnet.
When I run 'pihole reconfigure' it doesn't give any opportunity to specify the IP address manually but simply reads the current address. Consequently if the rpi is in the 172.16 subnet I am limited simply to changing the client number or the rpi will loose intenet connectivity and the reconfigure will fail. Simllarly if I start the rpi in the 192.168 subnet the rpi starts with no internet connectivity and the reconfigure process fails. Lastly, If i start in the 172.16 subnet and let pihole reconfigure do its startup checks and then change the rpi's IP address only when it asks me to make sure I have a static IP, then again it faisl. No doubt becuase It lost Internet connection.
There is an even more bizarre onset of network behaviour that seems to be due to pihole. If I move the rpi to the new subnet 192.168.0.0/24 and set its IP to 192.168.0.117 using the interface file (I have disabled NetworkManager) it exhibits very strange network behaviour. For details please see my posting on:
One would obviously expect pihole to fail under these cercumstances but not the network stack in general. At the moment this general network disfunction seems to be related to pihole, above and beyond any normal issues one might expect. It would seem to suggest pihole it tying itself directly into the network stack in some way and when it breaks it is breaking the network stack along with it.
This latter issue is preventing me from running pihole reconfigure in the 'new' target network because the rpi cannot get outgoing internet connectivity as the previously set ip address is attached to all outgoing traffic which is obvouisly a problem in the new subnet.
For a few years now, Pi-hole's installation script would inform you to set a static IP for your system yourself (by whatever means applicable to your host's OS), rather than offering to set a static IP address for you.
While the installer emphasises that static IP requirement, note that Pi-hole's DNS service would work without knowing the exact IP address, as it adopts automatically to any IP associated with the interface that you configure your Pi-hole to use.
However, there is one notable exception:
On systems with dhcpcd, the Pi-hole installer would offer to set an IP for you (mostly, Raspberry Pi OS up to RPi OS 10) via a dialog:
Choosing 'No' in that dialog should allow you to enter a custom IP.
If you do not see that dialog, then Pi-hole would not touch your system's network configuration, but use whatever IP address is already configured for your system.
You seem to suggest that Pi-hole's installer sometimes picks up 172.16.1.17 as IP address, which you want to avoid.
Pi-hole showing that IP during installation or reconfiguration would imply that your machine has acquired that IP, either because you've configured that IP manually on the machine hosting Pi-hole, or because you've configured that IP as a DHCP lease reservation in your router.
Consequently, you should check your Pi-hole host machine's network configuration as well as your router's DHCP configuration.
Pihole -v:
Pi-hole version is v5.18.2 (Latest: v5.18.2)
web version is v5.21 (Latest: v5.21)
FTL version is v5.25.2 (Latest: v5.25.2)
Blockquote You seem to suggest that Pi-hole's installer sometimes picks up 172.16.1.17 as IP address, which you want to avoid.
Blockquote
Sorry If I wasn't clear. The issue is that I can't successfully run pihole -r unless the subnet I place the Raspberry PI box on is 172.16.1.0/24. The network stack on the Raspberry Pi appears to be broken on any other subnet.
For example; if I set the Raspberry Pi address to 192.168.0.117 and place it on subnet segment 192.168.0.0/24 it manifests the following symptoms:
ifconfig and ip addr return the correct IP address as per the Interface file: 192.168.0.117.
I can ping this address locally on the PI box.
I can ping this address from another machine in the same subnet segment or from another subnet segment.
I can ssh to this address and 'all appears fine' on the Pi box.
Fine except for the fact there is no outgoing connectivity from the Pi Box. No HTTP no Ping or anything else.
When I run a packet capture on that subnet it shows that outgoing packets initiated from the Pi Box have the address 172.16.1.17. Which consequently are being blocked by the firewall because the Pi box is sitting within segment 192.168....
So far this is obviously strange behaviour but nothing necessarily to do with Pihole. The reason I'm pointing the finger at Pihole is because the 172.16.1.17 address doesn't seem to be present "anywhere" on the Pi box and dhcp is not active on the router. Even if it were the Pi box should be getting a 192.168... address. The only place I can find the 172.16.1.17 address is when I grep the binary file: /etc/pihole/pihole-FTL.db.
I do not know how or why the ip address sting being embedded within pihole-FTL.db would in anyway cause this strange behaviour of the network stack. But its the only place I can find that address on the PI box
Consequently I'm assuming there is some tie-in between pihole and the network layer through which this behaviour is being manifested. And some bug behind that which is causing the retention of the old ip address and its misassignment to the outgoing packets.
The fact that the Pi box cannot initiate outbound connections on any subnet segment other than 172.16.1.0/24 means that I cannot successfrully run pihole -r to change the address within pihole-FTL.db and hopefully 'fix' the problem.
Of course there is an assumption here and that is what I'm asking about: Could Pihole be causing this issue and if so how can I fix it?
I can run pihole -r on the 172.16.1.0/24 subnet but I can't change the ip address to one within the 192.168.0.0/24 subnet because 'pihole -r' is not giving me the option to set the ip address. It is just picking up from the eth0 address which I obviously had to set to a value within 172.16.1.X in order for the Pi box to have a working internet connection.
pihole-FTL.db is Pi-hole's long-term query database.
Any IP that has issued a DNS request to Pi-hole in the past will show up there.
Before Pi-hole Core v5.3, IP addresses were stored in setupVars.conf.
But as explained, Pi-hole does not depend on being configured for a specific IP address for quite some time now. Consequently, storing and accessing of IPV4_ADDRESS (and IPV6_ADDRESS) in setupVars.conf has been removed from Pi-hole's installer with Pi-hole FTL v5.8, Web v5.5 and Core v5.3 released in April 2021.
As you are running a current version, that would confirm that your issue is with your network configuration, which your Pi-hole wouldn't touch (unless your OS would run dhcpcd for network management).
As explained in my first post:
You won't get that option, unless your OS would run dhcpcd (mostly pre 12/Bookworm Raspberry Pi OS distros):
Your description suggests that you've tried to set a static IP on the host itself.
How did you do that?
Please try to upload a debug token after temporarily resetting the nameserver:
sudo nano /etc/resolv.conf
Edit the nameserver line to nameserver 9.9.9.9 or your preferred third party DNS service, save and exit.
Thanks for your reply it was very informative.
I shall start looking somewhere else for the rogue ip address.
In the mean time here are the respones to your questions.
I set the ip address from the interface file. NetworkManager has been disabled and masked.
Scanning all your interfaces for DHCP servers
Timeout: 10 seconds
* Received 300 bytes from wlan0:10.42.0.10
Offered IP address: 10.42.0.29
Server IP address: 10.42.0.10
Relay-agent IP address: N/A
BOOTP server: (empty)
BOOTP file: (empty)
DHCP options:
Message type: DHCPOFFER (2)
server-identifier: 10.42.0.10
lease-time: 259200 ( 3d )
renewal-time: 129600 ( 1d 12h )
rebinding-time: 226800 ( 2d 15h )
netmask: 255.255.255.0
broadcast: 10.42.0.255
router: 10.42.0.10
ntp-server: 192.168.0.1
dns-server: 192.168.0.117
--- end of options ---
DHCP packets received on interface eth0: 0
DHCP packets received on interface wlan0: 1
Here is my resolv.conf before pihole -d:
nameserver 9.9.9.9
#nameserver 192.168.0.1
I can't upload the debug.log as I don't have outward bound internet connectivity on the RPI configured for 192.168.0.x. so I've attached it to a reply email. Please let me know if there is some other method you would like me to use.
Mistery Solved.
It turned out to be an snat rule for the wifi located in the same file as the dnsmasq parameters.
When the file was flagged by the 'grep' search I only saw the parameters which got flagged and not the snat rule. I think I dismissed it without looking properly as I ASSumed the dnsmasq setting were irrelevant for the symptoms.
As SNAT is a firewall rule, and dnsmasq would not be involved in that, could you share the file and contents you've changed, for the benefit of others encountering your issue?
