
So how do you know that unifi can redirect traffic from same subnet to different IP on same subnet for dns? You have one and have done it? Or you read some blog or forum post that said it does this? Sure its not being done at the AP with wireless clients?
#Namebench outgoing requests intercepted how to#
I know that was a long one (sorry!), but I must be missing something - does anyone know how to achieve full invisible/transparent DNS interception so I can have my cake and eat it? I have attempted to use the same DNS redirection rule () to intercept and send all naughty DNS traffic to the Pi-hole's IP instead of pfSense, but this just results in clients that cannot resolve anything. The primary goal is for that traffic to behave as if the client had directly sent it to the Pi-hole, giving me nice helpful logs. I'm not bothered if the naughty device can tell traffic is being intercepted - if they see 8.8.8.8 or my Pi-hole IP in a dig lookup doesn't really matter to me. This will then keep the client happy (it thinks it's using its own hardcoded public DNS and its query was resolved), and I get to see exactly what/who made what lookups via the Pi-hole logs. What I ultimately want to achieve is the same as what Scott Helme has done with his UniFi USG setup (see ), where he intercepts the naughty DNS traffic, shoves it in the direction of the Pi-hole, which is then answered, and is then transparently masqueraded and returned back to the client. BUT, any intercepted DNS traffic then shows up in my Pi-hole dashboard and logs as originating from my firewall, which isn't useful. Functionally, this works and has the same end result: everything is using my Pi-holes. The closest I've come so far is to use pfSense to intercept DNS traffic, and using the forwarder, send the traffic to my Pi-hole(s), which then resolves the lookup normally via port 443 and Cloudflare. I also want to see exactly what lookups these devices are making. If a future IOT device has hardcoded DNS (and refuses to use my DHCP DNS), it will simply not function. Reasons I don't want to do this: I want those sneaky devices or people to have a functioning DNS, but on my terms.
#Namebench outgoing requests intercepted plus#
Yes, I could use pfSense's own resolver, plus use DoT, but I have a very nice Pi-hole setup with all kinds of advanced configuration that I want to use instead of the services that pfSense has. Reasons I don't want to do this: I don't want any DNS leaving my network unencrypted by using pfSense's own forwarder to a public DNS.


This all works fine, but I'd like to prevent any devices from using any DNS other than my Pi-holes. It serves my Pi-hole IP addresses to all clients via DHCP. I'm also running pfSense (obviously!).Ĭurrently, my pfSense firewall is the DHCP server, and I'd like to keep it that way.

Quick summary of my setup: I use two Pi-hole DNS machines, which are running the DNS-over-HTTPS service from Cloudflare.
