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 8.8.4.4) 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). - https://www.netgate.com/docs/pfsense/dns/redirecting-all-dns-requests-to-pfsense.html

    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 https://scotthelme.co.uk/catching-naughty-devices-on-my-home-network/#notalldevicesbehavethemselves), 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 8.8.8.8 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 (https://www.netgate.com/docs/pfsense/dns/redirecting-all-dns-requests-to-pfsense.html) 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 8.8.8.8 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 8.8.8.8 and was redirect to pihole, which logged it as my PC I did the query from I5-win box..

    0_1547114728799_redirectdns.png

    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 192.168.1.100 say with USG gateway being 192.168.1.1, can redirect traffic going to 8.8.8.8 53 to say 192.168.1.200 ?

    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?
    https://community.ubnt.com/t5/UniFi-Routing-Switching/Redirect-DNS-to-Pi-hole-using-a-USG/td-p/2436503

    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 (https://scotthelme.co.uk/catching-naughty-devices-on-my-home-network/#notalldevicesbehavethemselves), 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 (https://scotthelme.co.uk/catching-naughty-devices-on-my-home-network/#comment-3862737092) 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 192.168.1.1 which is the IP address of my USG"

    Your doing the same thing with the simple redirect to 127.0.0.1 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 8.8.8.8, and gets a response that is artificially from 8.8.8.8 (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.



  • @starrypenfold Did you ever get this to work the way you wanted (also, the way I need)?

    I currently have a very simple setup using a USG (192.168.1.0), pihole (192.168.1.2) and the code from Scott Helme's article. I'd like to move to pfsense and this one thing is holding me up.

    My setup allows the pihole to identify (in the log) the individual IPs of devices trying to bypass the pihole dns. I've had no issues with the masquerading with over a year of use.

    This is the json code that worked for me

    {
    "service": {
    "nat": {
    "rule": {
    "1": {
    "description": "DNS Redirect",
    "destination": {
    "port": "53"
    },
    "inbound-interface": "eth1",
    "inside-address": {
    "address": "192.168.1.2"
    },
    "source": {
    "address": "!192.168.1.2"
    },
    "log": "disable",
    "protocol": "tcp_udp",
    "type": "destination"
    },
    "6000": {
    "description": "Translate DNS to Internal",
    "destination": {
    "address": "192.168.1.2",
    "port": "53"
    },
    "log": "disable",
    "outbound-interface": "eth1",
    "protocol": "tcp_udp",
    "type": "masquerade"
    }
    }
    }
    }
    }



  • @ashman5 I haven't achieved masquerading DNS queries, no.

    For a while, I blocked all outgoing DNS on port 53.

    In the end, I've stuck with the simple 'Redirecting all DNS Requests to pfSense' rule (https://docs.netgate.com/pfsense/en/latest/dns/redirecting-all-dns-requests-to-pfsense.html), which will intercept, forward, and answer any outgoing DNS queries.

    I also added a rule to block all outgoing access to common and well-known DNS resolvers (8.8.8.8, 8.8.4.4, 1.1.1.1 etc.), as well as another rule blocking outgoing port 853 on TCP (DNS over TLS).

    It's not perfect, and wouldn't give me the insight of knowing exactly which client made the query, but it's a lot better than not having the rule at all. Blocking outgoing DNS also brings some peace of mind.


  • LAYER 8 Global Moderator

    @johnpoz said in Transparently Intercept and Redirect DNS Traffic to an Internal DNS:

    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.

    That is all that is required to see the client doing the request in your pihole logs... The pihole just needs to be on a different segment.. Then you can directly forward to it vs having to have unbound make the request via the loopback..

    Here, I setup on my lan (192.168.9/24) a port forward to my pihole which sits on my dmz segment (192.168.3/24)

    Did a query direct to outside, which see got sent to pihole, and pihole logged my client IP doing the query

    dnsredirect.jpg



  • Sorry to dig this up, I'm also coming from an EdgeRouter back to pfSense and you can redirect DNS queries to your pihole with pfSense easily.

    These are my NAT rules:
    alt text

    The outbound NAT is required to prevent the client from thinking the DNS is spoofed:
    alt text

    Without the above you'd get the following:

     dig @8.8.8.8 www.google.co.nz
    ;; reply from unexpected source: 192.168.1.250#53, expected 8.8.8.8#53
    

    The DNS alias includes my two piholes, pfsense and the pihole's VIP 192.168.1.250

    I can't recall the exact technical reason behind the masquerade NAT rule as I set this up on my EdgeRouter ages ago.

    Either way, if you'd set up something similar on your EdgeRouter or USG it will show the router's IP address on the pihole, unless it's in a different subnet per @johnpoz's comment.

    And the above ensures all DNS requests go via pihole, without the need for configuring firewall rules to block traffic.

    I don't know if this is the right way to do it on pfSense, this is just how I interpreted it based on my EdgeRouter config, so don't take it as the gospel of truth.



  • Ok let me give you people a few words of advice here:

    Think it through.

    Understand that in Routing, Brouting, Subnetting and Firewalling/Packet Filtering 192.168.1.0/24 IS NOT THE SAME.

    I'm not just intercepting DNS this way, but NTP as well (udp/123).

    What happens, let's assume the following setup:

    Local subnet is 10.1.1.0/24
    DNS-Server that the clients in the subnet try to reach is outside of the local subnet, let's say 1.2.3.4.
    Client is 10.1.1.10
    Your DNS-Server is 10.1.1.100

    So when a packet from a client in the local subnet hits pf it looks like this:

    From:10.1.1.10:23456 - To:1.2.3.4:53

    Now you want to intercept those packets, so you create a rule that changes the DESTINATION IP-address of the packet to your DNS server (DNAT), so the packet now looks like this:

    From:10.1.1.10:23456 - To:10.1.1.100:53

    Now this packet hits the routing table and after a lookup the kernel decides that the destination IP-address is on the local subnet and forwads the packet to the DNS-server.

    The DNS-server accepts the packet, takes care of the request and now sends an answer back to the client. It composes the answer packet by swapping source and destination, so the answer packet now looks like:

    From:10.1.1.100:53 - To:10.1.1.10:23456

    The packet gets send to the DNS-server's kernel's routing table, lookup is done, the kernel decides that 10.1.1.10 is on the local subnet and answers directly to 10.1.1.10.

    The packet is forwarded by the switch and hits 10.1.1.10. Now 10.1.1.10 looks at the following UDP packet:

    From:10.1.1.100:53 - To:10.1.1.10:23456

    It checks its state/connection table, doesn't find any such connection, doesn't listen on 23456/udp for generic requests and DROPS THE PACKET.

    And this folks is what they call NAT-Reflection. When the final DNS-server is in a different subnet, the problem you CAN run into is that the DNS-server uses a different default gateway and cannot send back the request to you, so you want to do the same little trick that follows now:

    So a few wise guys were hit by this problem before and invented SOURCE NAT.

    How you do it right:

    The initial packet is :

    From:10.1.1.10:23456 - To:1.2.3.4:53

    When the packet hits the firewall, you change the DESTINATION IP to your DNS-Server, so the packet now looks like this:

    From:10.1.1.10:23456 - To:10.1.1.100:53

    Any outgoing packet on your local subnet's interface that leaves towards 10.1.1.100:53 udp is now SOURCE NATED to your firewall's IP-address, so it looks like this:

    From:10.1.1.1:23456 - To:10.1.1.100:53

    Packet hits the DNS-server, request is taken care of, answer is composed, now the answer looks like this:

    From:10.1.1.100:53 - To:10.1.1.23456

    Packet hits the DNS-server's routing table, lookup is done and the packet is send out the local subnet's interface directly to the firewall.

    The firewall, with it's inglorious packet filter now knows how to take care of this package. It changes the destination back to 10.1.1.10:23456 and the source back to 1.2.3.4:53 and sends the following package back to the client:

    From:1.2.3.4:53 - To:10.1.1.10:23456

    The client receives the packet and is a happy camper.

    You gotta understand here that destination NAT happens BEFORE routing and source NAT happens AFTER routing. The Linux netfilter diagram makes that pretty good visible.

    https://i.stack.imgur.com/ifsxc.png

    While the things I explained above are a so called NAT-reflection problem, the same problem can occur when you DNAT everything to a DNS-server in a different subnet and said DNS-server only has a default gateway that doesn't know how to route to the client that did the initial request. So if you SOURCE NAT to the firewall's ip-address the way back is known to the DNS-server as there is obviously a connection already.

    pfSense offers a nat-reflection setting that does nat + proxy. You might want to use that one.

    You're welcome ;-P

    Cu



  • So if I'm following your logic, you're saying to use pure NAT with automatic outbound reflection enabled?

    I tried to do that, and not sure if I'm running into a bug but I keep getting:

    There were error(s) loading the rules: /tmp/rules.debug:81: syntax error - The line in question reads [81]: no nat on igb1 proto { tcp udp } from (igb1) to 192.168.1.250 port port
    @ 2020-02-09 20:05:04
    

    This is line 80-82:

    rdr on { igb1.20 igb1.30 l2tp enc0 } proto { tcp udp } from $LAN_Clients to ! $DNS port 53 -> 192.168.1.250
    no nat on igb1 proto { tcp udp } from (igb1) to 192.168.1.250 port port
    nat on igb1 proto { tcp udp } from 192.168.1.0/24 to 192.168.1.250 port port -> 192.168.1.1 port 1024:65535
    

    Happens in 2.4.4 p3 and 2.4.5-RC.. what am I doing wrong?



  • Hi,

    why the ! (not) on line 80? Is $DNS a server you can route to directly and that knows the way back to everything coming from igb1.20, igb1.30 l2tp and enc0?

    If that is so, a simple redirect of all DNS requests to that server should work and the firewall should change the answers back to the original destination automagically.

    Btw I wonder if "port port" on 81 and 82 are a broken template thingie in pfSense, you just using a weird name or what, but I think that's what's causing the main problem here...

    Anyway, you should create a port forward rule, yeah sounds weird, but that's where this part of the configuration is actually done. You'd have to do this for all interfaces where clients are making DNS-requests from so the igb1.*, l2tp and enc0 ones.

    The rule should look like this:

    Edit Redirect Entry:

    • Interface (pick one incoming interface, igb1.*, l2tp, enc0...)
    • Protocol UDP
    • Source (Display Advanced)
    • from any IP (any port to any port)
    • to any IP:53
    • Redirect target IP: DNS-Server-IP
    • Redirect target port: 53

    This fetches everything coming in on the interface in udp going to anywhere port 53 and redirects it to the DNS-server

    IF the DNS-Server ($DNS) does know the way back, this is NOT necessary:

    On the interface where those packets then leave towards the DNS-Server your create an OUTBOUND NAT rule:

    Edit Advanced Outbound NAT Entry:

    • Interface (outgoing interface, e.g. IF_INET)
    • Protocol UDP
    • Source any/any
    • Destination dns-server-ip/53

    Translation

    • Address: interface address
    • Port or Range: empty

    If you want to use udp/tcp and/or ipv6 just add it to the rules.

    CU



  • It seems to be something to do with using aliases in the rule that's causing that particular issue, I've submitted a bug report on redmine

    I have two pihole's behind a VIP, so the DNS alias contains 192.168.1.250 (VIP), 192.168.1.2 (pihole 1), 192.168.1.3 (pihole 2) and 192.168.1.1 (pfsense). The piholes forward the request to pfsense, pfsense forwards to my ISP DNS resolvers.

    So I have ! DNS to ensure that requests to any of these IP's don't get affected by the NAT rule. I want all clients in the DHCP ranges to use pihole's or pfsense's DNS only, for situations where devices e.g. NVidia Shield TV hardcode google DNS in certain places and apps.

    I'm not sure why all interfaces are specified in the NAT rule in /tmp/rules.debug, as I only have 3 NAT rules, 1 for each interface LAN, GWN and IOT.

    Anyway, what you've described above is mostly the same as what I've done including the outbound NAT rule so everything is working good for me atm 👍



  • This post is deleted!

  • LAYER 8 Global Moderator

    Not sure why you deleted the question.. But I will tell you - I trust the authoritative NS for the domain I am looking for something in.. Nobody else - why would I ask X for Y, when I can just ask Z directly hey what is the IP of host.domain.tld that you are authoritative for..

    Better yeah when they sign said info with dnssec. I would never forward all my dns request to anyone and "trust" them.. When I can just get the info direct from the horses mouth..

    When you resolve you ask roots, hey who is authoritative for tld, (signed) hey NS for tld who is authoritative for domain.tld (hope signed).. Ok thanks hey NS for domain.tld what is IP of host.yourdomain.tld (again hope signed).

    Why would I not do that vs asking hey billy what is ip of xyz.domain.tld - how do you trust that???



  • This has been a great source of info for best practice ways to setup a pi-hole with pfSense.

    For my homelab, I'm migrating away from a flat network and have been using what I've learned here to apply to my network.

    One issue that I'm having is that I would like to us the dns forwarder option because I don't want to edit my rules for things like IOT and Guest from knowing the IP range of another internal VLAN.

    My plan was to use the DNS forwarder but it points to the DNS IPs in System/General Setup/DNS.

    My issue is that I have all of my internal traffic ran through a VPN_GatewayGroup, including the pi-hole. The only thing I have coming out locally is the General Setup DNS to allow pfSense to be able to build the domain based vpn tunnels.

    The recommendation here with the rules and NAT looks good but no matter which VLAN I put the pi-hole there will be local services that need it. Is there a way to override the DNS Forward DNS address and let the pfSense itself continue to use the System/General settings?

    Thanks a bunch


  • LAYER 8 Global Moderator

    @cyrus104 said in Transparently Intercept and Redirect DNS Traffic to an Internal DNS:

    I would like to us the dns forwarder option because I don't want to edit my rules for things like IOT and Guest from knowing the IP range of another internal VLAN.

    Huh?? What does that have to do with using the forwarder or resolver?



  • If I just do as other suggest and put the pi-hole DNS server (on a different VLAN) in the DHCP than IOT / Guest devices will not only know the IP range they are placed into by dhcp but will also know about another network segment.

    So I would like to use forwarder / resolver but it seems like these require the use of the the System / General Setup / settings. If I make the pi-hole server the number one option here I think I have an issue on full reboot because all LAN traffic is forced out of VPN connection that aren't yet established and won't be due to the pi-hole dns being needing to go out of the LAN interface.


  • LAYER 8 Global Moderator

    @cyrus104 said in Transparently Intercept and Redirect DNS Traffic to an Internal DNS:

    Guest devices will not only know the IP range they are placed into by dhcp but will also know about another network segment.

    No they wont - since your doing an intercept of the dns traffic - they have no freaking idea where it got sent, for what they know is it answer from who they sent it too 8.8.8.8

    I even posted a screenshot showing that the query was to 8.8.8.8..

    What your pihole will know is the IP of the source who did the query.. But to the client he sent query to 8.8.8.8 and got answer, he has no idea it came pihole or any other internal dns server. Or what network pihole/dns was on..



  • Hey your the man, you've got 24k posts here and know more than probably anybody. I would ask that before you get your panties in a twist you read what people are asking. That sentence was specific to listing the DNS in the DHCP server section. In my limited understanding and testing of how DHCP works, when I put a DNS address in the DHCP it gets passed directly to the client.

    Both of my latest posts highlight that your method is probably best... but I still need a DNS solution for the VLAN / subnet that the pi-hole DNS solution is put on. I'm not putting it on my DMZ as you suggested but on a management vlan and need the other servers / services to have access to that vlan without hardcoding it into them.


  • LAYER 8 Global Moderator

    You can redirect traffic from pfsense on same segment, you just have to source nat it.. And now your pihole will not know that client X asked or client Y asked... Since it will all look like it came from pfsense.

    Is there a way to override the DNS Forward DNS address and let the pfSense itself continue to use the System/General settings?

    Yea set the forwarding in the custom option box vs using the checkbox.. Now you can point pfsense to whatever you want for dns

    @cyrus104 said in Transparently Intercept and Redirect DNS Traffic to an Internal DNS:

    eed the other servers / services to have access to that vlan without hardcoding it into them.

    Already went over how to do this..

    Here is what I would suggest, and why adding to OLD threads is problematic... Your ask or question really has ZERO to do with this thread.

    You should start your OWN thread, laying out your exact questions and what your trying to accomplish..



  • @johnpoz said in Transparently Intercept and Redirect DNS Traffic to an Internal DNS:

    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 8.8.8.8 and was redirect to pihole, which logged it as my PC I did the query from I5-win box..

    0_1547114728799_redirectdns.png

    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 ;)

    How can your PiHole see the Name of the Client? Mine only shows the IP :/


  • LAYER 8 Global Moderator

    Because pfsense knows the name, and it does a PTR for it..

    How pihole assigns name to an IP is via a PTR query for the IP..


Log in to reply