Transparently Intercept and Redirect DNS Traffic to an Internal DNS

  • Quick summary of my setup: I use two Pi-hole DNS machines, which are running the DNS-over-HTTPS service from Cloudflare. I'm also running pfSense (obviously!).

    Currently, my pfSense firewall is the DHCP server, and I'd like to keep it that way. It serves my Pi-hole IP addresses to all clients via DHCP.

    This all works fine, but I'd like to prevent any devices from using any DNS other than my Pi-holes. That may be in the form of IOT devices with hardcoded DNS (I believe I caught a Ring Chime using the other day. Or potentially, it could be someone that decides to be clever and change their client's DNS settings to use Google DNS/OpenDNS etc.

    I've done a fair bit of reading around the forums, and all I've seen and been able to achieve so far is:

    1. Create a NAT rule that intercepts all LAN traffic (port 53), and answers the lookup at the firewall itself (either via its own DNS resolver or forwarder). -

    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. 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. In short, for DNS I want all devices using the Pi-hole, and nothing using the pfSense.

    1. Block any DNS (port 53) traffic leaving the network that isn't going to the 'correct' IP (my Pi-hole), thereby giving devices the 'choice' to either have no DNS at all or give up and use the DNS I've given it via DHCP.

    Reasons I don't want to do this: I want those sneaky devices or people to have a functioning DNS, but on my terms. If a future IOT device has hardcoded DNS (and refuses to use my DHCP DNS), it will simply not function. I also want to see exactly what lookups these devices are making.

    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. Functionally, this works and has the same end result: everything is using my Pi-holes. BUT, any intercepted DNS traffic then shows up in my Pi-hole dashboard and logs as originating from my firewall, which isn't useful.

    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. 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.

    I'm not bothered if the naughty device can tell traffic is being intercepted - if they see or my Pi-hole IP in a dig lookup doesn't really matter to me. 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 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.

    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?

  • LAYER 8 Global Moderator

    Why do you not just run dns on pfsense, and have it forward to your pihole.. That way the interception rule works, and gets sent to pihole...

    Via your redirecting all dns requests link.

    Do you can either run unbound in forwarding mode, forwarding to your pihole boxes, or dnsmasq the pfsense forwarder, again just forwarding to your pihole.

    All your normal clients will just ask pihole, stuff that tries to ask for example will get redirect to pfsense service, which just forwards to pihole, which in turn forwards via tls to cloudflare. Guess you really want cloudflare to know everywhere your devices go ;) hehehe

    All this fine and dandy until these iot devices get smart enough to just do their dns via tls ;)

  • Thanks @johnpoz, that does work (intercepting with pfsense then using the forwarder to the Pi-hole), but it also means that those requests all log as originating from the router as opposed to the client - I want my Pi-hole logs to show exactly which 'true' IP initiated the request.

    Is it not possible to re-write the traffic in this way with pfSense? I can't imagine UniFi would out-do pfSense...

    Yes, I'm aware that Cloudflare will see all our DNS lookups, but I trust them more than my ISP or whomever else could nab the traffic or acquire it afterwards :)

    Regarding devices using DoT/H in future, that's something we will all have to address, at which point blocking may be the most suitable answer.

  • LAYER 8 Global Moderator

    You can do it when the dns server is on a different network.. Here I create a redirect on my lan network 192.168.9/24 to redirect to my pihole which is on my dmz or 192.168.3/24 network..

    So you can see I did a query to and was redirect to pihole, which logged it as my PC I did the query from I5-win box..


    Where your going to have problems is trying to redirect traffic in and out the same interface with a port forward.

    Move your pihole to its own segment and you will be fine.

    As to unifi, not sure how they do it? Haven't look into it - but if you think they are out doing pfsense... Have at it ;) I had to run their USG for a while.. Their dns features are WAY behind... Well all their feature to be honest.. Creating a simple firewall rule was a PITA... Running multiple vlans, again PITA, etc..

    I have the USG sitting on my self... Let you have it at pfsense forum users discount if you want it ;)

  • @johnpoz That's a great help, thank you :)

    I see what you mean. That's a shame it can't be done on the same subnet, but I will look into moving the Pi-holes to another subnet. I'll probably stick with forwarding via pfSense until I have that up and running - at least the primary goal will be achieved, then I'll fix the logging later.

    I don't expect UniFi to be more capable than pfSense at all - hence my surprise. I was considering UniFi a few years back before I heard about pfSense, but thanks for the offer ;)

  • LAYER 8 Global Moderator

    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?

    Your saying client A at say with USG gateway being, can redirect traffic going to 53 to say ?

    I will have to do some looking into that - can always fire up the USG for testing to see how they do it.
    Is this what you found?

    that is going to show all queries coming from the USG IP... Where exactly did you find setup that forwards to downstream dns and still keeps the same query IP as original?

    BTW that sure looks like one hell of PITA to setup vs clicking a couple of drop downs in a gui ;) heheheheheeh And I can not find anything that would have pihole logging the original IP of the requester.. So its the same thing pfsense can do for you with a couple of clicks..

  • I haven't achieved it myself, but according to Scott Helme's article (, it seems to be possible with UniFi on the same subnet (see his third dig command screenshot).

    There is some discussion in the comments that some clients do not like the 'faked' traffic, and won't resolve. However, someone pointed out ( that masquerading the traffic is possible, which seems to keep devices happy. But yes, same exact thing as the Ubuquiti forum post you refer to.

  • LAYER 8 Global Moderator

    But my point is - look where the query came from... That is NOT his client IP.. But that is the IP of his USG...

    "You can also see in the query log that the DNS request came from which is the IP address of my USG"

    Your doing the same thing with the simple redirect to and forwarding... So you can accomplish exactly what they are doing with 5 seconds worth of clicks in the pfsense gui.. Vs loading that json file, etc. etc.

    If you want to see the original query clients IP, then you need to just put your pihole and port forward on a different network than your clients on. Which you could prob do on the USG as well - but wow would it be a pain in the ass vs couple of clicks in a gui ;)

    So did you want to reword this statement? ;)

    I can't imagine UniFi would out-do pfSense...

    Don't get me wrong for the price point the USG is not a bad little unit, and with some work it can do some kewl stuff.. But anything over your basic stuff is just painful to get working.. And while it can push some packets at that price point - which is what I needed it for until my sg4860 got off backorder.. If you wanted to do its pretty neat dpi stuff its routing speed drops into the dirt.. Since you had to turn off the hardware offload to use that feature.

    Once my sg4860 got here, I couldn't move off that thing fast enough.. It was painful! doing even the most basic firewall rules. In the same ballpark price point you now have the sg1100 which should be a usg killer ;) hehehe for those at that budget level. And don't get me wrong if I had just come from your typical soho router/firewall it would be the cats meow for sure... But being spoiled with having used pfsense for the last 10 some years.. Yeah its no where close to the level of pfsense at all.

  • That's very true - I'd missed that his log was showing the router's IP, whoops :)

    I'm not sure how to explain the third dig screenshot though - it seems like his client asks for, and gets a response that is artificially from (even though it actually came from his Pi-hole). Or am I misunderstanding that?

    I said I can't imagine it would out-do pfSense ;)

    I certainly agree with you on capability. I've recommended the USG to some friends that would have been far less comfortable with pfSense, and needed something simple that largely 'just worked' out of the box with some future control if they wanted to delve a little deeper. In their case, they were upgrading from crappy ISP routers, and I didn't want to recommend an off-the-shelf consumer router from Asus, Netgear etc.