That's strange. I actually found the reason why REPLY_ADDR4 in my pihole-FTL.conf always got overwritten with the wrong IP on every container restart. I overlooked, that I had set a wrong value for the ServerIP env variable in the docker run command, i.e. I used a shell substitution, that returned the physical interface IP:
And TBH, I'll probably keep this permanently, because it allows me to push my router's IP as a secondary DNS server again, as I used to do with my former plain dnsmasq setup before switching to pihole.
Just to make sure: you did a āpihole restartdnsā after changing the FTL config right? And maybe cleared clients DNS cache. That worked for me, always, during all the testing.
Well, not exactly, but yes. I'm using the docker version and do a docker restart pihole after config changes, which of course also restarts the dns service.
Yes, it says that:
[...]
[2021-10-18 16:45:17.633 418M] EDNS0_ECS: Overwrite client from ECS information
[2021-10-18 16:45:17.633 418M] REFRESH_HOSTNAMES: Periodically refreshing IPv4 names
[2021-10-18 16:45:17.634 418M] RATE_LIMIT: Rate-limiting client making more than 1000 queries in 60 seconds
[2021-10-18 16:45:17.634 418M] REPLY_ADDR4: Using IPv4 address 192.168.4.250 in IP blocking mode
[2021-10-18 16:45:17.634 418M] REPLY_ADDR6: Automatic interface-dependent detection of address
[2021-10-18 16:45:17.635 418M] SHOW_DNSSEC: Enabled, showing automatically generated DNSSEC queries
[2021-10-18 16:45:17.635 418M] MOZILLA_CANARY: Enabled
[...]
But even then it pushes the physical interface's IP (192.168.4.248) as the only DNS to clients.
I need to explicitly configure dhcp-option 6 in /etc/dnsmasq.d/10-custom-dns-override-dhcp.conf to override this behavior.
For my use case I'm perfectly fine with configuring the correct dns servers with a config file in dnsmsq.d. It just didn't occur to me until I read this tip somewhere else.
The config should restrict dnsmasq to listen only on eth0 (and lo as it always does this). However, dnsmasq fails to identify the receiving interface as label and, accordingly, fails to reject the queries received on virtual interfaces even though it should do this. This causes issues later in FTL as the label interface is correctly ignored and, hence, the interface address of this interface is not known.
There are two ways this can be fixed:
Please try
pihole checkout ftl tweak/virtual_interfaces
which should ensure that virtual interfaces are analyzed even if they are not configured. This ensures the dnsmasq bug about not differentiating between interfaces and labels thereof is a "consistent bug".
Try changing the setting to Listen on all interfaces and see if this fixes the issue for you even without the fix above:
edit Connected pull request
edit 2 I don't think the bug be fixed easily enough in dnsmasq as all this virtual interface stuff is pretty obscure and a lot of low-level networking features used here cannot distinguish virtual interfaces from the real physical ones.
Update: that happens even when changing nothing and just clicking SAVE. For sure another issue and not related
Result option 2: Yes, that works! I chose "Listen only on interface eth0" because there were and might be again soon wireless interfaces so that option made/makes sense. So I tested option 1:
Option 1: That tweak works too! As with this one I can stick to my "Listen only on interface eth0" setting and kick the REPLY_ADDR4 option in /etc/pihole/pihole-FTL.conf IĀ“m preferring this solution.
Thanks for those additional two options and all the analyzing efforts you put in
Just one last question: when will this tweak/fix (FTL) be available in master branch? I donĀ“t want to forget to switch back by running pihole checkout ftl master and/of finally kick the REPLY_ADDR4 option.
On the next regular Pi-hole release. We don't have any strict plans, it's ready when it's ready. It mostly depends on if we've had time to sit down and do all the required testing prior to a release.
I'm using the docker version and do a 
