Please follow the below template, it will help us to help you!
Expected Behaviour:
Unifi DHCP name server set to Pihole's IP address so the USG can hand out the Pihole's DNS. This does work, however, on VLANs, the clients connected get "DNS Timeouts" several times per minute.
Actual Behaviour:
Here's the setup:
Unifi Controller (USG) on latest firmware with 1 LAN and 2 VLANs (1 for IoT and the other for security cameras). Pihole with Unbound on Raspberry Pi.
Before splitting IoT devices and my security cameras off onto their own VLANs, this setup worked perfectly. Since then, the devices on the 2 VLANs constantly get "DNS Timeouts" in the Unifi Controller and the Roku on the IoT VLAN sometimes won't connect.
I have the Pihole's IP address in the DHCP name server field of the Unifi Controller, so the USG is successfully handing out the Pihole DNS. I have firewall rules set up in the Controller to allow the new VLANs to talk to the Pihole (192.168.1.188) and Port 53.
As I mentioned, the VLAN devices ARE getting the correct DNS (192.168.1.188) but something isn't right.
Does anything look off in the debug log? I've been googl'ing this for almost a full day now and have tried many, many things/suggestions but none have seemed to solve the "DNS Timeout" error I keep seeing in the Unifi Controller.
This is likely owed to the fact that your VLAN operates on a different subnet (e.g.192.168.2.0/24) or even a different local network entirely (like 10.10.10.0/24), while your Pi-hole is registered within your router's default network 192.168.1.0/24.
As such, it is not a Pi-hole issue, but I'll try to add what little knowledge I happen to have.
That quickly boils down to two options.
1. Masquerade your DNS requests (I'd prefer this - click for more)
By (sane) default, Pi-hole will listen on the subnet that's tied to its network interface, i.e. 192.168.1.0/24, so it won't hear requests from your VLAN.
You have to find a way to make your USG forward DNS requests from your VLAN to your Pi-hole, probably masquerading them to originate from the USG.
As you mention
I know USGs to provide a command prompt (CLI), but are not familiar with the software running on it, nor of the extent Ubiquiti Inc. allows interfering with it.
But if you've done firewall config by means of iptables, you could try employ masquerading as follows:
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
This would alter the source address of any packet passing through your USG and leaving it via eth0 to your USG address. If your Pi-hole does not live at eth0 in your USG, change the interface accordingly, and you might want to add an extra -i wlan0 option to limit this to your VLAN attached interface (again, use the appropriate interface name).
Of course, this relies on your forwarding rules being setup correctly, namely just for DNS.
Your Pi-hole will then be able to hear the requests, as they will appear to come from your USG on Pi-hole's network. However, you'd forfeit the ability to assign VLAN activities to a specific VLAN client in Pi-hole's query log - they all appear as your USG.
There might be configuration options that allow for improving this, but they are beyond my current knowledge (and of course, I am totally clueless when it comes to USG, as I don't have one).
2. Allow Pi-hole to accept ANY traffic, regardless of origin (potential security issue! - click for more nonetheless)
Alternatively, you could try changing Pi-hole’s DNS settings for its Interface listening behaviour to “ Listen on all interfaces, permit all origins ”, but heed the advice on that page:
should not be used on devices which are directly connected to the Internet
Even if this does solve your problem, it still would definitely be preferable to have your USG configure access to Pi-hole correctly.
As this is not strictly Pi-hole specific, you might have better luck looking for a solution in Ubiquiti's forums.
No doubt you have done this already, but maybe my musings could offer a different angle for your search.
Good luck, and let us know if you found a solution worth sharing
First off, thank you so much for the reply. It's been a frustrating journey to say the least. Yeah, I did post this same thing on the Ubiquiti forums. The only response I got so far was that my firewall rules should be in GUEST_IN instead of LAN_IN but I don't think that's right since both VLANs are Corporate and not Guest.
I also have firewall rules to allow the VLANs to talk to the Pihole (in that direction but not the other way Pihole to VLANs), but they don't seem to be working. Admittedly, I'm not 100% sure all of my firewall rules are working or are even correct. I could definitely use some eyes on them to make sure they make sense and aren't opening me up to more risk.
And yeah, I wasn't exactly sure if this was a Pihole thing because of Unbound or a Ubiquiti thing because of what you said - the VLANs being on different subnets. I'll give your links a try and see what shakes loose. I'm definitely leaning more towards option 1, as option 2 is just too risky.
I'm open to try almost whatever at this point, though. If I find the answer or if anyone else has any other suggestions, I'll post them here. I know there are others who are experiencing this, too.
It seems Ubiquiti has developed it's own software layer above whatever tools they employ on their hardware (I very much suspect those tools to be standard Linux, though).
I have stumbled across these CLI recommendations, but alas:
They seem to be for their Edge Router (click for details)
Enter configuration mode.
configure
Add the NAT Masquerade rule.
set service nat rule description 'masquerade for Pi-hole DNS'
set service nat rule outbound-interface eth1
set service nat rule type masquerade
set service nat rule protocol all
Commit the changes and save the configuration.
commit ; save
I have altered the statements a tiny bit to better reflect your config, but you still have to adopt eth1 to the interface that your USG uses for connecting Pi-hole (make sure it's hard-wired ethernet, though).
And chances are this won't work readily (or at all) on your device if it isn't of the said Edge Router variant...
Yeah, the EdgeRouter and USG are different devices entirely. I've read things suggesting EdgeRouter configs can be "translated" to USG configs, but I don't know what that means or how to even do that. The interfaces are completely different and I don't know if the USG CLI has the same capabilities as the EdgeRouter CLI.
To your last comment, what do you mean:
adopt eth1 to the interface that your USG uses for connect Pi-hole
That's showing the network interface on your Pi-hole machine. It's good it is using ethernet, as this is more reliable than WiFi, and it also means you most likely have a dedicated route to your USG (where wlan -or an intermediate switch- would mean you possibly share the connection with other clients).
However, to configure your USG, you have to know into which of the USG's Ethernet-LAN-Port the cable leading to Pi-hole is plugged in. Likely, your USG has more than one ethernet port.
So: Which port is your Pi-hole connected to on your USG?
It's a different device, yes. The USG is just the LAN/WAN gateway - my router. The switch is a managed switch. FiOS Gateway feeds the USG WAN port --> USG LAN port feeds into port 1 of the Switch giving internet to all of the APs connected to the switch.
You didn't mention a switch before - this makes it a tiny bit harder to apply my first option, as your USG receives traffic from multiple clients via one network interface only now (as aggregated by your switch).
Thus, we cannot apply rules on a network interface level, as all clients on that interface would be affected. We'd have to alter my above statement from being interface specific
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
to being specific for the destination address:
iptables -t nat -A POSTROUTING -d 192.168.1.188 -j MASQUERADE
This still leaves the problem how to apply this to your USG rules.
Could you try if you can run iptables directly by executing iptables -S or sudo iptables -S from your USG CLI?
Alternatively, maybe time to discuss option 2:
Do you expose any of your local network devices to the public internet?
So, yes. I was able to run sudo iptables -S from the USG CLI. It spit out all of my firewall rules set in the Unifi Controller.
As for option 2:
When you say "expose"...network my devices are as such: 2 desktops, 2 laptops, 2 iPhones, 1 Roku, 2 Smart TVs, 6 security cameras - all which require internet access.
The devices on the LAN are the desktops, laptops, and iPhones (the other devices are on the VLANs). As of this moment, each of these LAN devices is using the Pi-hole as the DNS and none have public DNS set. Also, they're all connected to Unifi APs that are connected to the Unifi switch I mentioned which is sitting behind the USG.
Sort of - it seems your devices contact the internet, but I couldn't access any of them, like if you were running a public webserver (which you don't, right?).
Any expected fallout from running this? Is my wife going to run in here in 5 minutes with a knife because I ruined her watching her Netflix cooking show?
Difficult to foresee - I do not know Unifi devices.
You can always delete the rule if you encounter difficulties, but that involves a bit of querying rules and noting down numbers - refer to e.g. How To List and Delete Iptables Firewall Rules for details on how to do that.
Also, we might have to tune that statement to better match your setup.
We have just covered the output side, but we likely have to add some input side restrictions, as the current will mask DNS queries of any origin.
It might be safer to do this when a) your wife is not in a position to excercise immediate retribution (i.e., away from home), and b) I am a bit more awake and available (it's well past midnight for me now).
We can definitely table this until tomorrow or whenever. It's not crippling the network, it's just frustrating. I also will do more research tonight (since I'm 6 hours behind you) on USG iptables and seeing if there are any other recommended or suggested configs.
I've seen a lot of other people making custom configs and pushing it up to their Cloud Key, which I do not have yet. So, any changes I make to iptables won't be persistent if I were to reboot or have an outage or something.
