Transparently Intercept and Redirect DNS Traffic to an Internal DNS
-
@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 ;)
-
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/2436503that 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.
-
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.
-
@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
-
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:
The outbound NAT is required to prevent the client from thinking the DNS is spoofed:
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#53The 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.100So 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:04This 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:65535Happens 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! -
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
-
@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.
-
@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.
