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:
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: NXDOMAIN
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.
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.
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:
scutil --dns: 10.247.71.249
nslookup: 10.247.71.2
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.
@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:
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.
deHakkelaar is right about taking this one step at a time.
Let's briefly return to what we already had established:
jfb's analysis of your debug log has shown your Pi-hole to be fully operational.
However, nslookups and traceroutes as suggested by jfb and deHakkelaar have revealed connectivity issues. Those types of issues are most likely related to your router's configuration.
As you are trying to setup Pi-hole in a single VLAN only, it's unlikely that this is related to routing, as you would not need to cross subnet boundaries in that scenario.
This leaves firewalling or port-forwarding as possible causes, as well as issues with handling DNS traffic itself (like a possible DNS loop I mentioned before).
We're all willing to help you on your way, but with regards to your router, you'll have to find out for yourself. I, for once, have never heard of or dealt with a Pepwave device before, so am not aware of your router's capabilities, its limitations and restrictions. We can point you into a general direction, but you'd have to go the last mile (or a few more) by yourself. That's why I suggest you to also consider using additional sources of support with your router.
So, when following the steps from your other topic, do not set Pi-hole as your DNS server yet.
Let's first try to establish that your devices are indeed on the same subnetwork by running ip address show
from your Pi-hole machine as well as from your Macbook, both connected to your IoT-VLAN.
And try to ping each device from the other by their respective IP address, e.g. ping -c 3 10.241.71.<x>
where <x> is replaced by the correct number.
Good advice - I'll check connectivity before enabling Pi-Hole as DNS. Before seeing your previous advice I re-flashed my card, so I'll be starting over, and this time I'll try covering all of the VLANs using Pi-Hole as DNS, and the router as DHCP, with the RPi on my main LAN in order to make it easier to reach. This config appears more popular and thus I can find more instructions.
WRT to the router, the Pepwave Surf SOHO is a low-end business router, with good support and frequent firmware updates. It's being discovered by people who want better than mass market router security but who don't feel up to open source routers.