My Pihole (with unbound) seems to work ok on my LAN for a while, however I never managed to have it working on my VLANs.
as soon as I was setting the PiHole IP in the VLAN configuration, I wasn't able to resolve any query.
I fixed the firewall and add the PiHole as DNS for the VLAN again, weirdly I seems to resolve DNS query although they are all unfiltered.
I don't see any of the VLAN's IP on the PiHole webIf (Query Log, and Network tab)
I don't really understand as both the LAN and the VLAN have the same DNS configuration now, and clearly my IoT VLAN have it's queries resolved (unless somehow he is using unbound bypassing PiHole ?
I've the same setup (Unifi, VLANs, Pihole) and it's working as expected - so it should be possible to solve.
ATM you can query pihole from within your VLAN but in the log and and network table the client doesn't show up and nothing is blocked?
Try pihole -t to see a live output of pihole.log and do a DNS request for flurry.com from a client in our VLAN. The request should show up. Check if the request is also visible in the Web Interface Query log.
Don't route DNS Traffic from VLAN to VLAN but instead add some VLAN Interfaces to your Pi-Hole Server so it has a simple local connection with every Client in each VLAN
If you want I can write up a Tutorial for this in English ?
But it will not solve the problem @kevincork is facing, as even with the current setup DNS queries are answered by pihole but apparently not logged to the query log and not blocked.
I have the same setup with routed VLAN traffic (might change that to your approach) and I do see the clients and queries in the log.
Your (partially sanitised) debug log looks normal.
(Uploading it and just posting a debug token here would limit your audience to a few trusted developers and mods for 48 hours only.
In case you'd prefer to send us a sanitised file nonetheless, you could initiate a manual tricorder upload for that sanitised file as described in How do I debug my Pi-hole installation?)
This could hint at something intercepting DNS traffic on your network, redirecting it to a different DNS server.
Check whether your router would offer such a feature and try to disable it.
Also, try the following commands from a VLAN client - they should all result in 0.0.0.0:
nslookup flurry.com
;; connection timed out; no servers could be reached
Actually you was right, I totally forgot that I had content filtering for the IoT VLAN and a secondary VLAN... so when disabled I have no DNS resolution at all, Likely to be something wrong with my firewall then I guess
I was a bit conscious about this but I did set to all origins for a minutes, but it's still doesn't resolve anything.
I bet I did something wrong with the firewall (again...) I'll try to change some rules
I think you told me a few week ago that my firewall rules was wrong and I think you was right at the end !
I don't really understand what I did wrong but I did :
1.allow all the VLANs and DNS PORT (53) to PI hole IP and Port 53.
2. allow Pi Hole / Port 53 > Local VLANs - Port 53
3. Block DNS : source port 53.
you was probably right with port 53, I thought it was a bit dodgy not to restrict to this port but that probably where the issue is
UPDATE : just to confirm, your firewall settings + Listen on all interfaces, permit all origins work. just a bit worried security wise but it's work ! thank you!
Check your ACL orders. Some firewalls will apply 2003 first and stop further processing. Some will apply 2005 first and stop further processing. Some will apply 2003 and continue to process, meaning 2005 is applied after 2003. You may need to do a default blocking of all DNS first and then allow specific entries after.
ACLs are a bear to get right, you may need to do some digging in your firewall manuals.
With my rules their should be no need for "Listen on all interfaces, permit all origins". Your router (USG/UDM) does the inter-VLAN routing and packets from VLANs arrive at your pihole via eth0 (or equivalent). So setting it to "Listen only on interface eth0" should be sufficient.
ADD
Thanks to Dan for the hint.
For UniFi devices the order is
firewall rules are processed in top-to-bottom order.
right, not sure why it only worked with "Listen on all interfaces, permit all origins" on my first attempt earlier, but it's working now with " Listen only on interface eth0" (I should probably have more patience and wait a bit more...)
any way all shorted, thank you all !