Where does Pi-Hole save Network / Interface settings files?

[mx2k]

Hello community,

I'd need to know where Pi-Hole saves the configuration files regarding interface IP settings, and especially where static IPs are defined.

I checked some tutorial about Linux networking, so I checked /etc/network/interfaces, but to no avail.

My issue is, that I might have defined or tried to define some IPs manually, which now needs to be removed. I did this ages ago while still experimenting, thus not with pihole -r, as intended. So I basically forgot which files I edited back then.

So, please kindly let me know where I would most likely find the Pi-Hole / Linux config files where the static IP settings are defined for IPv4 and v6.

Is there maybe some neat Linux command that I can run to search all files for the IP in question as search condition?

Thanks in advance.

[Daxtorim]

Pi-hole appends the static IP you set during initial setup to /etc/dhcpcd.conf.

[mx2k]

Thanks for pointing this out.

Under the risk of going off-topic again, I want to reach Pi-Hole Web interface on port 80 from external. Just for the purpose to get it to work.

So, the Pi-Hole has MAC: b8:27:eb:67:aa:a7

Pi-Hole got this fe80::e9dc:8727:cead:f6c8 from somewhere. I have not defined it manually and its definitively some generated IP. However, I conclude it is not based on EUI-64.

I actually remember the e9dc:8727:cead:f6c8 part of the IP. Before IPv6 ISP, force assign ULA was enabled on my network. Somehow, this IP was originally assigned/generated with ULA. However, ULA is now "disabled", but the IP kinda sticks and avoids all my approaches to replace it with the now required EUI-64.

Router support guy told me, device needs to provide EUI-64 link local address - or bust.

Therefore, I require the Pi-Hole to forget any old stuff and have assign/generate new EUI-64 IP/Interface ID to make IPv6 port forwarding work. As per calculator, it must look like FE80::BA27:EBFF:FE67:AAA7 - based on my prefix and the device MAC.

For some unknown reason, Pi-Hole sticks to this fe80::e9dc:8727:cead:f6c8 IP and wont generate a new one using the EUI-64 automatically.

• So, please can anyone tell me. How to Force Pi-Hole / Linux to forget old, apparently random, currently assigned IP fe80::e9dc:8727:cead:f6c8. This even reads valid_lft forever with ifconfig and thus wont just change/renew by itself, it seems.

• And regenerate a new, proper IP using EUI-64 and the device MAC address, so it will become unique, static FE80::BA27:EBFF:FE67:AAA7.

There is some Linux command to be able to force IPv6 fe80: regeneration, right?

---

Or well, I have had a look at /etc/dhcpcd.conf. Maybe its long story short. There is this setting slaac private, which reads "generate .... instead of hardware based one"

This isn't actually what's causing the described issue, or is it?
Because, yes, I have a somewhat stable, generated IPv6 - but its not based on hardware address. That reads a bit like what's happening here.

If that is actually the cause, please just tell me how to disable it?

Also I already posted all my IP questions to some IPv6 forums, as it was suggested to me in responses to some of my other posts. Sorry to say, still getting the best answers here. Should buy you a coffee or something

Or maybe I just need to throw cash at it, buy a new Ras-Pi with a different MAC and just hope all stuff there gets assigned properly on 1st contact to my network.

[Daxtorim]

@mx2k

This isn't actually what's causing the described issue, or is it?

Yep, that should be exactly what is causing this. IIRC the alternative was something simple like slaac hardware, but check the man page for dhcpcd for the required spelling of "hardware".

[Bucking_Horn]

@mx2k

buy a new Ras-Pi

That won't do you any good, as RFC 7217 address generation as configured by slaac private is the default for Raspberry Pi OS.

Note that switching back to EUI48/64 identifiers (which will never change for a given network interface) will not only make your device trackable, but also expose your MAC to the public.

If I remember correctly, the screenshot of your router from another post exposed entry fields for your RPi's IPv6 interface identifier.
Since you also mentioned you have enabled DHCPv6:
Did you consider to use those entry fields to manually assign a fixed interface identifier to your RPi and check whether your RPi would pick that up via DHCPv6?
That should serve the same purpose as EUI48/64 addresses.
A fixed interface identifier would still leave your RPi trackable, but at least you wouldn't expose your MAC.

Another approach would be to enlist the services of a DynDNS provider and install the DynDNS client software on your RPi running your VPN server.
While that client would take care of updating your public DNS records once your RPi's IPv6 address changes (regardless whether it has changed its prefix or interface identifier or both), you should then be able to access your VPN server by domain name rather than by IP - provided your router can be configured to allow access to your VPN ports.

And finally, as a more restrictive and maybe less ideal approach, you should be able to avoid those IPv6 issues altogether if accessing your VPN by IPv4 only would be a viable option for you.