Hello,
I am using the lastest Docker Version installed on my synology.
The routeur FreshTomato IP ; 192.168.1.1
All options under DHCP and DNS are disbaled on the routeur.
Synology IP : 192.168.1.10
PiHole is set up as DNS + DHCP server and for now I disabled the adblocking.
Ring and Google Home work.
Ring and Google Home not working. I suspect because the DNS settings are hardcoded in there, but I am not sure.
Your debug log shows you don't have an IP address on eth0.
*** [ DIAGNOSING ]: Networking
[✗] No IPv4 address(es) found on the eth0 interface.
Your Pi-hole should be using bond0 interface:
default via 192.168.1.1 dev bond0 src 192.168.1.10
Try to set the environment variable INTERFACE=bond0 to your container.
Hi Rob and thanks for your reply. I tried with the INTERFACE=bond0 but no luck.
Here is the latest https://tricorder.pi-hole.net/GSqtva2N/
I am really desparate now. I spent hours and hours on that. I can not find a solution.
Why is it working on all network except the ring and google home decives? Do you think the issue comes from the Tomato Router?
Once again DHCP and DNS is on PiHole.
Thanks
By "not working", what are the specifics for these devices?
The won't connect to the internet, you can't see them in the respective apps, etc.?
Thanks @jfb , you are right. We need more info.
I see the GoogleHome device in PiHole with an IP : [192.168.1.176]
It is really complicated to see what is actually happening on the device itself as it is totally closed.
Here is what happens when i connect the device to the internet using my phone as a hotspot.
1- I reset the device Google Home
2- I use my ipad and use the Google Home app to link the device to the HotSpot.
3- I follow the installation tutorial and it gets connected and at the end, the Google Assistant Respond to queries like "He google what time is it?".
Now when I try to do the same but on my network, it seems to connect but at the end the Assistant never respond. The only reply I get is "Google Home is not installed... use google home app to connect it"...
FYI, Remember that I disable the adblock on pihole for the purpose of those tests.
I also just tried to by pass using dhcp-option on my routeur. With no luck. Note that to run this tests I activated few options on my FreshTomato Routeur
Is there anyway to capture the port 53 request from those devices where the DNS servers is hardcoded?
A bit like I used to do on my Tomato routeur?
Or is it done on pi-hole?
I am a bit lost in terms of routing?
The device with the hardcoded DNS URL, first goes to the Gateways right. And then on the gateway I have the Pi-hole DNS and DHCP, but the device will ignore the DNS no? He will request an IP to the DHCP on PiHole and then not ask anything regarding the DNS and use its own? .... No idea.
Anyone help?
It's not entirely clear how exactly your different configuration of NAS, router and Pi-hole work together and what exactly those screens would convey. I am not familiar with your router or your NAS at all, so you should consider consulting their respective documentation and support for issues specific to them.
If I read your configuration correctly, your router is distributing its own internal DNS server to clients via DHCP, not Pi-hole, and you've configured your router to use Pi-hole as its upstream DNS resolver on the WAN side.
A client's DNS resolution chain would thus be
client -> router - > Pi-hole -> Pi-hole's upstream DNS
That is a valid configuration, but note that you won't be able to attribute DNS requests to individual clients in Pi-hole's Query Log, as all DNS requests originate from your router.
It is quite possible that your observation is caused by your problematic devices trying to access a domain that is blocked by Pi-hole. How do I determine what domain an ad is coming from? may help you to find those domains.
It seems you tried to address your issue by configuring your router to allow your problematic devices to use Google for DNS instead of your router.
In general, that should work as well, as that would remove Pi-hole from their DNS resolution chain altogether: client -> 8.8.8.8.
But you mention you have or had configured a forceful redirection of port 53 DNS traffic in your router. In that case, while your client would still send their DNS requests to 8.8.8.8, your router would intercept and redirect them, so you'd end up with:
client -> 8.8.8.8 -> router (intercepted) -> router's upstream, i.e. Pi-hole -> Pi-hole's upstream DNS
Obviously, this would counteract your intention of having those devices by-pass Pi-hole.
There are possibly several approaches to address this.
One would be to switch your router's upstreams from Pi-hole to a public DNS resolver of your choice, and have your router distribute Pi-hole as its only DNS local DNS resolver via DHCP while keeping your router's extras for your problematic devices.
That should result in the following DNS resolution chains:
normal clients:
client -> Pi-hole -> Pi-hole's upstream DNS
clients tagged to by-pass Pi-hole:
client -> 8.8.8.8
If you stick with forcefully redirecting your port 53 DNS traffic, you should exempt Pi-hole from that rule.
Any client by-passing Pi-hole, tagged as allowed or not, would then be subject to the following DNS chain:
client -> public DNS resolver, e.g. 8.8.8.8 -> router (intercepted) -> router's upstream (public DNS resolver)
I can't advise on the actual configuration settings of your router.
You should refer to your router's documentation and support for details. 
Thanks @Bucking_Horn for your explanations.
I have reviewed my approach in a more simple way.
I moved back the DHCP to the routeur. The DNS is done by PiHole.
It all seems to work, but I get some DNS Leaks. I can not find a way to solve it.
PiHole is using OpenDNS.
My computer has hardcoded DNS to CloudFlare.
When I check my DNS on https://www.dnsleaktest.com/ I see that the computer is NOT using OpenDNS. That is therefore a DNS leakage.
How can you solve that issue on a FreshTomato routeur?
Thanks
Is it really?
You would use the term DNS leakage only when you would make use of a VPN service, where you'd expect DNS traffic to travel via your VPN exclusively.
When DNS traffic would be flowing outside your VPN, then you'd have a DNS leakage.
With a normal ISP connection, the 'DNS leakage test' will just show the DNS servers that your network is currently using - and that wouldn't imply a DNS leakage at all, since those are the DNS servers you did configure yourself.
From your description, I would expect those to be at least OpenDNS (as used by your Pi-hole) as well as Cloudflare (as used by your computer).
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.
