Hello,
I spent a bit of time trying to get my computers and devices to see the pi-hole I set up for testing purposes, and any DNS resolution they required failed out, after pointing them to the pi. The pi-hole's logs don't show requests coming in from any network devices; all devices are on the same subnet, port 53 isn't blocked, firewall on the pi itself isn't running, etc. The admin page is accessible via IP, but never at pi.hole.
What am I missing? Does FTL require more setup?
further information: I have a DHCP server already, so am not using the pihole for DHCP, just DNS.
pihole -g shows 81745 unique domains in gravity, all checks green.
Thanks in advance
From a client that you believe should be connected to the Pi-Hole for DNS, from the command prompt or terminal on that client (and not via ssh or Putty to the Pi), what is the output of
nslookup 192.168.1.216:
connection timed out; no servers could be reached
same for pi.hole.
dig @192.168.1.216 times out as well:
; <<>> DiG 9.16.1-Ubuntu <<>> @192.168.1.216
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
No firewall running, this box is behind my normal firewalls, so I hadn't set one up yet.
The interface in question has two inet6 addresses, which surprises me. My internal network is just running inet though, so I'd been ignoring it:
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether b8:27:eb:f6:0a:d7 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.216/24 brd 192.168.1.255 scope global wlan0
valid_lft forever preferred_lft forever
inet6 fd16:3b9b:e002:1:35b1:ed04:e798:a3af/64 scope global mngtmpaddr noprefixroute dynamic
valid_lft 1777sec preferred_lft 1777sec
inet6 fe80::a790:927:dac2:6d4e/64 scope link
valid_lft forever preferred_lft forever
It's not unusual for a device to have a multitude of IPv6 addresses.
Besides, IPv6 isn't involved (yet), as that nslookup was directed specifically at Pi-hole's IPv4 address.
This leaves two other possible explanations:
a) another process on your Pi-hole machine snitches port 53 from Pi-hole
However, according to your debug log, this doesn't seem to be the case.
b) another networking device -your router or a dedicated firewall machine- blocks access to port 53 to your local Pi-hole.
Hm. that's what I was afraid of. I don't see firewall rules about port 53 on anything so far, or about that IP address. I didn't deliberately set it up, so now I'm working on the assumption it's something default-denied that I have to allow. I'm on an ASUS wireless router operating in AP mode, connected wired to my main router; the first device I tried this from was wireless-only (my phone), so I'm suspicious of the wireless router. Haven't found anything yet, unfortunately.
That confirms your debug log output's "Ports in use" section and my earlier remark:
So Pi-hole is the only process listening on port 53 on your machine, leaving other network devices as a probable cause.
Note that some ASUS routers are reported to always distribute their own IP address as DNS server via DHCP alongside any DNS servers you've configured through your router's DHCP settings.
While that would allow clients to by-pass Pi-hole via your router's IP, I'd expect your nslookup to return NXDOMAIN rather than timing out in that case.
That is to say that I'm not sure how that would contribute to explain your observation.
It probably could if your AP mode router would close a DNS loop with your main router (where your two routers keep forwarding DNS requests among themselves until time-out) - but that is a fair amount of speculation on my behalf.
You should consider consulting your router's documentation channels for information how it would handle DNS in AP mode, and if and how you can configure DNS in that mode.
Besides from said ASUS routers, I have seen reports in the past about Google Nest (and some other routers also from Google (my memory may be incorrect here...)) actively intercepting any port 53 traffic. Said user was never able to get it running but then they connected the devices behind a cheap simple network switch and everything started to work instantaneously. They replaced the Google router which was the only sensible thing because it was doing something your don't want as user.
hm. I have an entirely too heterogeneous network layout. It's also apparently possible that my cable modem is blocking 53, though how that would affect my internal network I'm unclear on.
Thanks for the help, I'm going to try moving it to physical ports around the place and see if I can isolate which device is the problem.