I expect Network would show devices using Pi-Hole
Three devices listed in Network Overview: router, Amazon Fire Stick, and Apple MacBook Pro, all show Device does not use Pi-Hole.
The Query Log show four queries blocked - 2.3%. Default Blocklist chosen at installation, and two domains whitelisted since then.
Your debug log shows that the Pi-hole is receiving traffic only from itself or the host platform.
[2020-03-07 13:12:12.012 981] Imported 92 queries from the long-term database
[2020-03-07 13:12:12.012 981] -> Total DNS queries: 92
[2020-03-07 13:12:12.013 981] -> Cached DNS queries: 23
[2020-03-07 13:12:12.013 981] -> Forwarded DNS queries: 69
[2020-03-07 13:12:12.013 981] -> Exactly blocked DNS queries: 0
[2020-03-07 13:12:12.013 981] -> Unknown DNS queries: 0
[2020-03-07 13:12:12.013 981] -> Unique domains: 39
[2020-03-07 13:12:12.013 981] -> Unique clients: 1
From the Apple MacBook Pro terminal (and not via ssh session to the Pi-hole), what are the outputs of the following commands:
nslookup pi.hole
scutil --dns
abc@JC-MacBook-Pro RaspberryPi % nslookup pi.hole
;; connection timed out; no servers could be reached
abc@JC-MacBook-Pro RaspberryPi % scutil --dns
DNS configuration
resolver #1
nameserver[0] : 10.247.71.249
if_index : 4 (en0)
flags : Request A records
reach : 0x00020002 (Reachable,Directly Reachable Address)
resolver #2
domain : local
options : mdns
timeout : 5
flags : Request A records
reach : 0x00000000 (Not Reachable)
order : 300000
resolver #3
domain : 254.169.in-addr.arpa
options : mdns
timeout : 5
flags : Request A records
reach : 0x00000000 (Not Reachable)
order : 300200
resolver #4
domain : 8.e.f.ip6.arpa
options : mdns
timeout : 5
flags : Request A records
reach : 0x00000000 (Not Reachable)
order : 300400
resolver #5
domain : 9.e.f.ip6.arpa
options : mdns
timeout : 5
flags : Request A records
reach : 0x00000000 (Not Reachable)
order : 300600
resolver #6
domain : a.e.f.ip6.arpa
options : mdns
timeout : 5
flags : Request A records
reach : 0x00000000 (Not Reachable)
order : 300800
resolver #7
domain : b.e.f.ip6.arpa
options : mdns
timeout : 5
flags : Request A records
reach : 0x00000000 (Not Reachable)
order : 301000
DNS configuration (for scoped queries)
resolver #1
nameserver[0] : 10.247.71.249
if_index : 4 (en0)
flags : Scoped, Request A records
reach : 0x00020002 (Reachable,Directly Reachable Address)
abc@JC-MacBook-Pro RaspberryPi %
This command was not asnwered by the assigned DNS server.
This shows that the Mac is trying to use Pi-hole for DNS.
From the Mac terminal again, what are the outputs of the following:
nslookup pi.hole 10.247.71.249
nslookup flurry.com 10.247.71.249
From the Mac Terminal, on the affected VLAN, each has the same response:
;; connection timed out; no servers could be reachedNo internet from that VLAN - I had to change to another to post this response.
[code]
The problem may be in the VLAN setup. Unless you are routing port 53 (DNS) traffic between VLANs, clients won't all be able to find the Pi-hole if it on a different VLAN.
Yes - the VLANs are set up with no communication between VLANs, so that would be normal. In this case, however, I was unable to reach the internet from the VLAN that the Pi-Hole is on. That is unusual.
Use below tool on Linux based systems to check ICMP (ping) connectivity:
traceroute -n <IP>
For Windows you have similar tool:
tracert -d <IP>
Run below one on Pi-hole and on the clients (Linux/Windows/MacOS) to check DNS port 53 UDP connectivity using the OS configured DNS server(s):
nslookup pi.hole
Run below one on Pi-hole and clients to address a specified DNS server:
nslookup pi.hole <DNS_SERVER_IP>
Pi-hole only does DNS filtering and as you might have noticed, above connectivity tests are all IP based (not domain name based).
So if have issues with any of above ones, you have to check your VLAN setup and maybe route 53 UDP & TCP between the VLAN's.
Or you could assign multiple VLAN's to the Pi-hole port on the switch and let Pi-hole have a foot in all the net segments (multi homed).
Checkout below posting how to get as many IP's configured (IP aliasing) as you like on one physical (or virtual) interface:
Before I shift back to the IoT VLAN with no browser connectivity for the traceroute test, here's a result of a recent ping test from the IoT VLAN:
abc@JC-MacBook-Pro RaspberryPi % ping -c 2 149.112.112.112
PING 149.112.112.112 (149.112.112.112): 56 data bytes
64 bytes from 149.112.112.112: icmp_seq=0 ttl=52 time=44.229 ms
--- 149.112.112.112 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 43.317/43.773/44.229/0.456 ms
64 bytes from 149.112.112.112: icmp_seq=1 ttl=52 time=43.317 msI'll try to absorb what you've written and be back with the other results.
ping if you know its only one hop away.
traceroute for when have multiple hops to get to target.
I agree. This single VLAN approach was supposed to be easy for me to understand; I don't, and I've used up far too much of your time.
Here are the results you asked for, but if the issue isn't immediately apparent to you, I think I'll flash the SD card with the image I made before this Pi-Hole installation and start over with Pi-Hole-as-HDCP for the whole network.
A: From Mac
traceroute -n <IP> # to local dns or upstream?
From MacOS to 9.9.9.9:
abc@JC-MacBook-Pro ~ % traceroute -n 9.9.9.9
traceroute to 9.9.9.9 (9.9.9.9), 64 hops max, 52 byte packets
1 10.247.71.2 3.289 ms 1.894 ms 1.050 ms
2 * * *
3 24.28.133.105 34.281 ms 26.082 ms 23.693 ms
4 24.175.33.136 18.062 ms 10.708 ms 12.594 ms
5 24.175.32.176 13.437 ms 13.238 ms 11.517 ms
6 24.175.32.156 18.547 ms 20.637 ms 22.447 ms
7 66.109.9.88 21.099 ms
66.109.6.108 22.372 ms
66.109.9.88 22.467 ms
8 * 4.59.126.33 19.881 ms 625.187 ms
9 * * *
10 4.68.62.178 44.642 ms 47.680 ms 42.737 ms
11 9.9.9.9 57.476 ms !Z 41.492 ms !Z 44.291 ms !Z
From Mac to 10.247.71.249:
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
nslookup pi.hole
1. From PiHole (below)
2. From Mac:
abc@JC-MacBook-Pro ~ % nslookup pi.hole
Server: 10.247.71.2
Address: 10.247.71.2#53
** server can't find pi.hole: NXDOMAIN
nslookup pi.hole <DNS_SERVER_IP> #upstream or local?
1. From PiHole (below)
2. From Mac:
to 9.9.9.9:
abc@JC-MacBook-Pro ~ % nslookup pi.hole 9.9.9.9
Server: 9.9.9.9
Address: 9.9.9.9#53
** server can't find pi.hole: NXDOMAIN
to 10.247.71.249:
abc@JC-MacBook-Pro ~ % nslookup pi.hole 10.247.71.249
;; connection timed out; no servers could be reached
B. From PiHole:
pi@raspberrypi:~ $ traceroute -n 9.9.9.9
traceroute to 9.9.9.9 (9.9.9.9), 30 hops max, 60 byte packets
1 10.247.71.2 2.132 ms 1.849 ms 1.739 ms
2 * * *
3 24.28.133.105 31.088 ms 31.050 ms 31.011 ms
4 24.175.33.136 13.027 ms 13.023 ms 13.330 ms
5 24.175.32.176 14.581 ms 14.549 ms 14.511 ms
6 24.175.32.156 20.762 ms 23.501 ms 24.317 ms
7 66.109.1.218 21.879 ms 66.109.9.88 15.515 ms 66.109.1.218 21.815 ms
8 * * *
9 * * *
10 4.68.62.178 43.236 ms 42.105 ms 39.582 ms
11 9.9.9.9 36.619 ms !X 37.171 ms !X 36.979 ms !X
pi@raspberrypi:~ $
pi@raspberrypi:~ $ nslookup pi.hole
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: pi.hole
Address: 10.247.71.249
pi@raspberrypi:~ $
pi@raspberrypi:~ $ nslookup pi.hole 9.9.9.9
Server: 9.9.9.9
Address: 9.9.9.9#53
** server can't find pi.hole: NXDOMAINAll the output posted is as expected except below two:
Are they both in the same subnet ?
ip -4 a
ifconfig
Could be rebind protection or similar preventing lookups on private DNS IP's:
Also try set below on the Pi-hole web GUI and do the failed traceroute/nslookup again :
Ps. From below output, the Mac currently isnt configured to use Pi-hole but instead uses 10.247.71.2 for DNS resolution:
WRT the IoT VLAN, the default gateway is 10.247.71.2, and the DHCP IP range is 10.247.71.20 to 10.247.71.250. The Pi-Hole IP address is a DHCP reservation - 10-247.71.249. This might be the issue - me misunderstanding where I should aim something.
There's no mention in the router user manual (Pepwave Surf SOHO Mk3, v8.01) of rebind. It does mention, "When DNS forwarding is enabled, all clients’ outgoing DNS requests will also be intercepted and forwarded to the built-in DNS proxy server.," but I have not enabled it.
I'll have to run the other commands tomorrow.
This is the subnet mask I mean (255.255.255.0 in my case):
Mine is eth0.....
inet 10.247.71.249/24
pi@raspberrypi:~ $ ip -4 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
** inet 127.0.0.1/8 scope host lo**
** valid_lft forever preferred_lft forever**
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
** inet 10.247.71.249/24 brd 10.247.71.255 scope global noprefixroute eth0**
** valid_lft forever preferred_lft forever**
**pi@raspberrypi:~ $ **
After "Listen on all interfaces" set to "Listen on all interfaces, permit all origins:"
pi@raspberrypi:~ $ ip -4 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
** inet 127.0.0.1/8 scope host lo**
** valid_lft forever preferred_lft forever**
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
** inet 10.247.71.249/24 brd 10.247.71.255 scope global noprefixroute eth0**
** valid_lft forever preferred_lft forever**
pi@raspberrypi:~ $ **
pi@raspberrypi:~ $ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
** inet 10.247.71.249 netmask 255.255.255.0 broadcast 10.247.71.255
** inet6 fe80::d3cb:c2a1:92d7:43a4 prefixlen 64 scopeid 0x20**
** ether txqueuelen 1000 (Ethernet)**
** RX packets 511 bytes 324391 (316.7 KiB)**
** RX errors 0 dropped 0 overruns 0 frame 0**
** TX packets 466 bytes 55039 (53.7 KiB)**
** TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0**
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
** inet 127.0.0.1 netmask 255.0.0.0**
** inet6 ::1 prefixlen 128 scopeid 0x10**
** loop txqueuelen 1000 (Local Loopback)**
** RX packets 1645 bytes 3320920 (3.1 MiB)**
** RX errors 0 dropped 0 overruns 0 frame 0**
** TX packets 1645 bytes 3320920 (3.1 MiB)**
** TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0**
wlan0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
** ether txqueuelen 1000 (Ethernet)**
** RX packets 0 bytes 0 (0.0 B)**
** RX errors 0 dropped 0 overruns 0 frame 0**
** TX packets 0 bytes 0 (0.0 B)**
** TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0**
pi@raspberrypi:~ $
From something you wrote - I have not found any directions to set my MacBook or streaming devices' DNS, so I haven't. I did try re-setting a device (an AVR) but it didn't seem to affect anything so I put it back the way it had been previously.
I just realised that this is a cross-post / follow up from Plan for installing Pi-Hole on single, tagged VLAN - #5 by clicker.
It might help to know that clicker is originally aiming to have Pi-hole filtering just a single VLAN for IoT devices, configured through a Pepwave Surf SOHO Mk3 router.
Note that jfb has analysed your debug log and confirmed that Pi-hole is up and running - it is your clients that are not using Pi-hole, and that is something that has to be configured in your router.
Regarding the current findings for nslookups forced through Pi-hole's IP:
A time out could be happening if your router would block your DNS traffic or if you'd configured a DNS loop, e.g. if you had DNS forwarding enabled, with Pi-hole again being set as DNS server.
A firewall rule on your router could also explain the failing traceroute from your Mac to Pi-hole on the same subnet.
As @deHakkelaar has also observed, the following two results from your output contradict each other by showing different DNS server IPs on your Mac:
That could be explained by a configuration change.
You wouldn't have changed your VLAN configuration in between those two statements (in order to reestablish Internet connectivity fopr your IoT), would you?
And let me repeat my suggestion from your original thread here:
Though we are happy to help you with anything Pi-hole and also may have hints on general types of configuration, providing advice for specific router settings quite possibly exceeds our knowledge.
You may increase your chances for a quick and more knowledgeable answer if you additonally consult your router’s documentation and/or forums on how to specifically apply DNS related settings.
I think it's less likely to be an issue with the router than it is to be a lack of my knowledge of networking. I did not know, for instance, that I needed to change the DNS address on my devices.
Could I have altered the configuration? Yes - I have to alter it each time in order to access the Pi-Hole and run the requested checks, as I have no connectivity with it without "Assign DNS server automatically" enabled. I could easily have neglected to re-enable it properly between subsequent runs. More importantly, I did not pick up on the import of deHakkelaar's observations.
Cookbook or context? Right now I need cookbook, and that means following a more-traveled path - Pi-Hole as DHCP, so I'll re-flash the card to a backup image recorded before the current PiHole installation, and begin again.
You do not have to - it is just another way to enforce usage of Pi-hole.
The effect is the same as if successfully distributing it via DHCP.
Both approaches - router or Pi-hole as DHCP server - are known to work (if supported).
I don't have numbers on this, but I'd guess that Pi-hole as DHCP and DNS would be less used than just DNS - at least the guides I am aware of favour the latter.
And you don't have to flash a new image, switching DHCP on and off can easily be done from Pi-hole's web interface.
Super @Bucking_Horn for chiming in!
@clicker , you were to run below on both Pi-hole and the Mac client to see if subnet mask match:
The problem is, as you noted yourself, you lack some knowledge on important bits to be straight diving into the deep with VLAN's and such.
A method of diagnosing is to minimize.
Meaning, remove all parts from the system that are not necessary for a simple working state (resolving DNS via Pi-hole from a client).
Once you have a working state, you add components/complexity one by one (eg. involve DHCP, VLAN, VPN, own recursive DNS server etc).
Before diagnosing DNS resolution (the core of Pi-hole), you need to fix IP connectivity first (nslookup/ping/traceroute).
When have fixed the connectivity issue, you could configure one client to use Pi-hole for DNS by manually configuring network settings on the Mac client:
When the nslookup's are successful, you can deploy Pi-hole for the whole network by configuring DHCP like described in below FAQ:
And proceed by adding complexity.
That's the nub of the issue.
Before seeing Bucking-Horn's suggestion that I don't need to re-flash, I already had done so. I now have a few tools - thanks - to determine whether I have connectivity, and I'll see if that points me in the right direction.