The issue I am facing:
I am running pihole in a docker on a qnap NAS. After updating the container in container station, running pihole in bridge mode with privilege rights, my LAN connected devices (TV, Netatmo, Sonos, etc.) are not connected to internet, by my WLAN connected devices (Mac, iPhone) seems to work normally. I am also relying on PiHole's DHCP server (after disabling my Router's one).
From the debug log it seems that my device is not recognises:
*** [ DIAGNOSING ]: Operating system
[i] Pi-hole Docker Container: 2024.07.0
[i] Distro: Debian
[i] Version: 11
[✗] dig return code: 9
[✗] dig response: ;; connection timed out; no servers could be reached
[✗] Error: dig command failed - Unable to check OS
Details about my system:
PiHole in docker bridge mode on qnap NAS
What I have changed since installing Pi-hole:
I cloned the latest image and set up a new docker container replacing the old one.
Yes my MacBook has internet and works as intended, but it´s hard to tell because all devices I can access by terminal are functioning. Its only the "peripheral" devices which don't seem to work:
TV
Netatmo
Some Sonos speakers
If I try the command above with a specified ip the connection times out. Below is an attempt for one of the Sonos speakers:
(base) fs@Florians-MacBook-Pro ~ % nslookup pi.hole 192.168.1.229
;; connection timed out; no servers could be reached
However, I can ping the ip
(base) fs@Florians-MacBook-Pro ~ % ping 192.168.1.229
PING 192.168.1.229 (192.168.1.229): 56 data bytes
64 bytes from 192.168.1.229: icmp_seq=0 ttl=64 time=4.408 ms
64 bytes from 192.168.1.229: icmp_seq=1 ttl=64 time=5.181 ms
64 bytes from 192.168.1.229: icmp_seq=2 ttl=64 time=4.916 ms
64 bytes from 192.168.1.229: icmp_seq=3 ttl=64 time=5.190 ms
^C
--- 192.168.1.229 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 4.408/4.924/5.190/0.317 ms
Then they probably are connected, but dislike Pi-hole's blocking.
You could inspect Pi-hole's Query Log to learn which domains a specific client IP has requested and how Pi-hole processed them, e.g. by clicking on such a client as shown in Pi-hole's dashboard under Top Clients.
That's expected - you are misunderstanding what that nslookup does.
You are asking 192.168.1.229 for DNS resolution, but there is no DNS server on 192.168.1.229.
Ok, that's bad - not necessarily related to your issue, but bad, as your router's DNS server has handled that query, i.e. your Pi-hole may be by-passed via IPv6.
That definitely needs attention.
But let's first see how Pi-hole would handle that query:
No, Pi-hole has handed out a DHCP lease (as you should be able to verify by inspecting Pi-hole's DHCP leases and your TV's queries), it just refused the name that device was trying to claim for itself. (I guess that TV is perhaps an older Samsung model, as they are notorious for naming themselves localhost (which is really stupid to do, as any device will use that name internally))
If you want a nice name for your TV, create a static lease reservation with a Hostname for that TV in Pi-hole's DHCP server, or just add a Local DNS record.
But it doesn't contribute to your observation.
That's strange, as your macbook had no issues talking to Pi-hole in your earlier lookup:
How is your macbook connecting to your router, via ethernet or wifi?
And could you run that nslookup from your Pi-hole machine?
That would suggest that either Pi-hole is down, or a firewall on your NAS is blocking port 53.
However, as earlier lookups through 192.163.1.35 succeeded, the former seems more likely.
Is 192.168.1.35 your NAS, or just your Pi-hole container?
Another possible explanation would be that you haven't set a static IP on your NAS, and that it has relinquished its 192.168.1.35 after its (router issued) DHCP lease expired, or that you're running your Pi-hole container in macvlan mode, as Docker's macvlan isolation prevents direct communication between your Pi-hole container and the Docker host (but the latter wouldn't explain why your macbook suddenly also fails to contact 192.168.1.35).
And you also may see timeouts if your Pi-hole's upstream servers would be inaccessible.
