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:
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.
1 Like
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.
1 Like
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.
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.
It's set up with Pi-Hole as the DNS and the router as HDCP, covering all the VLANs. I'm still having trouble with the DNS:
the Pi-Hole is using the proper DNS IP, while the devices are all using the main LAN's default gateway for DNS, even though I changed them on each VLAN page. I'll talk to the router folks about this.
I'm making progress on this and thought I'd report my findings so far. Starting simply, on the router's main untagged LAN I haven't had to change anything on the router itself.
The most important change I did make has been to the ufw firewall. On all previous installations Pi-Hole said it detected a firewall and would I like it to open the default ports - I said okay. It turns out there were no ports opened by the installer, so I added two:
"sudo ufw allow from 10.xxx.xxx.0/24 to any port 53" (and then "80").
On installation I agreed to the keeping the Pi's current IP as static, then went into the router and gave that IP as Reservation.
The Mac laptop still didn't point to the Pi-Hole as DNS, even after renewing leases, so I added the Pi manually as DNS.
That seems to work, a little. On the Mac terminal "grep nameserver <(scutil --dns)" shows the Pi's IP. Using dig instead of nslookup, for "dig flurry.com" it does resolve it. The Mac now shows in green in the Pi's Network tab.
Also, the Pi-Hole Query Log shows Flurry.com as Blocked (gravity). The only problem is that is the only thing it has blocked out of 146 queries from several news sites.
Do I still have a problem?
Thanks for the update - a new debug token may help us to better assess your current Pi-hole configuration.
That firewall rule seems a bit tight if you want to expand providing Pi-hole to other subnets as well some time later, and it would also lack IPv6 specifics if you'd plan on using IPv6.
I assume that ufw is running on your Pi-hole machine, so you may want to consult corresponding Pi-hole's documentation.
Do you still intend your router to distribute Pi-hole via DHCP for IoT devices on a VLAN?
Then that would imply a configuration problem in your router.
Even if manual override works on your Mac, you may run into IoT devices that do not allow manual DNS configuration.
flurry.com should be resolved to 0.0.0.0 if you run that DNS request through a standard Pi-hole with default blocklists.
What does it resolve to on your Mac?
Thanks. Token: https://tricorder.pi-hole.net/kmtonzx1k2
[quote="Bucking_Horn, post:27, topic:29231"]
That firewall rule seems a bit tight if you want to expand providing Pi-hole to other subnets as well some time later, and it would also lack IPv6 specifics if you’d plan on using IPv6.
[/quote] Right - it's part of the "start small and add complications" effort. I won't be using IPv6 any sooner than I have to. I can add two more addresses for the two VLANs or learn something about subnet masks and do it all at once when they're needed.
Yes, it is, and I'll do that. I'm surprised that the Pi-Hole installer didn't add the rules - it implied it would.
"Even if manual override works on your Mac, you may run into IoT devices that do not allow manual DNS configuration."
Yes - that concerns me and implies I don't have a handle on this situation.
It resolves to zero zero zero zero on both Pi and Mac.
Edit 1: I got my first two blocks that weren't flurry.com - maybe it's working. I'm running only the default blocklists.
Edit 2: My iPhone is using Pi-Hole without my manually adding it to the phone.
Your debug shows Pi-hole as up and running with flawless IPv4 connectivity, but still shows only one client (i.e. Pi-hole itself) is using it -much as it has been before, I am afraid:
[2020-03-13 10:25:42.978 986] Imported 87 queries from the long-term database
[2020-03-13 10:25:42.978 986] -> Total DNS queries: 87
[2020-03-13 10:25:42.978 986] -> Cached DNS queries: 31
[2020-03-13 10:25:42.978 986] -> Forwarded DNS queries: 56
[2020-03-13 10:25:42.978 986] -> Exactly blocked DNS queries: 0
[2020-03-13 10:25:42.978 986] -> Unknown DNS queries: 0
[2020-03-13 10:25:42.978 986] -> Unique domains: 30
[2020-03-13 10:25:42.978 986] -> Unique clients: 1
[2020-03-13 10:25:42.979 986] -> Known forward destinations: 2
It should at least have registered your flurry.com queries, but has indeed blocked no DNS query so far (which is in line with no other client than Pi-hole).
How did you observe your other two blocks?
With regards to your firewall,
Why do you think that Pi-hole didn't add any rules?
Console log:
2020-03-13 15:02:52 A s.marketwatch.com (Mac LAN IP address) Blocked(gravity) ##This is my iPhone
...
2020-03-13 12:51:37 A stats.wp.com localhost Blocked(gravity)
...
2020-03-13 12:45:06 A www.smokersopinionpoll.com raspberrypi Blocked(gravity)
When I looked at it (sudo status verbose) the only rules were the ones I put there previous to installing Pi-Hole. After I installed them (and manually added the DNS to the Mac), things appeared to work a little. As I mentioned, I did not add my iPhone's DNS manually. There are a few others, but these are examples of the types.
Edit: Here's a fascinating one: 2020-03-13 15:07:02 A amazon-adsystem.com (ip address of Amazon fire Stick that's on an entirely different LAN/VLAN) Blocked(gravity). It shouldn't be reachable - different VLAN, no inter-VLAN routing, DNS servers automatically.
That Query Log excerpt of yours looks good. 
Does your Macbook show up there as well by now?
ufw is a convenience frontend for iptables.
Pi-hole adds its firewall rules directly to iptables, the command to list them is:
sudo iptables -L
for IPv4 rules.
Edit: removed the IPv6 part for now, to keep it simple.
I am not sure whether ufw is clever enough to pick those up automatically, but I am confident Pi-hole does add them if it says so.
Excellent - maybe you just created that former token too early 
We have mutiple clients now, and a few blocks as well:
[2020-03-13 14:36:27.066 981] Imported 314 queries from the long-term database
[2020-03-13 14:36:27.066 981] -> Total DNS queries: 314
[2020-03-13 14:36:27.066 981] -> Cached DNS queries: 75
[2020-03-13 14:36:27.066 981] -> Forwarded DNS queries: 230
[2020-03-13 14:36:27.066 981] -> Exactly blocked DNS queries: 9
[2020-03-13 14:36:27.066 981] -> Unknown DNS queries: 0
[2020-03-13 14:36:27.066 981] -> Unique domains: 102
[2020-03-13 14:36:27.066 981] -> Unique clients: 4
[2020-03-13 14:36:27.066 981] -> Known forward destinations: 2
And by the way:
You can also use nano /var/log/pihole_debug.log on your Pi-hole for analysing your installation yourself
Thanks. I didn't think to look below ufw.
Yes, but it was showing up when I added the DNS manually. My iPhone added itself after an invitation (it's on the same SSID/LAN).
Bu why did Amazon add itself? I never provided it with an SSID password?
Pi-hole is not concerned with authentication or routing at all.
That would be your router's job.