Transparently Intercept and Redirect DNS Traffic to an Internal DNS
-
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.
-
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..
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 :/
-
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..
-
@johnpoz I tried this setup and it works, as in I do get the right host name at the pihole end, but I get the following error as well:
❯ dig @8.8.8.8 dns-redirect-test.com ;; reply from unexpected source: 192.168.8.2#53, expected 8.8.8.8#53 ;; reply from unexpected source: 192.168.8.2#53, expected 8.8.8.8#53 ;; reply from unexpected source: 192.168.8.2#53, expected 8.8.8.8#53 ; <<>> DiG 9.10.6 <<>> @8.8.8.8 dns-redirect-test.com ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached192.168.8.2is the IP of the pihole.
LAN1 (on which all devices sit) is192.168.7.x
LAN2 (on which pihole sits) is192.168.8.xProbably something to do with properly setting up an outbound NAT rule but I've tried diff configs, none seem to resolve the issue.
Any pointers are welcome.
-
@ibbetsion
The NAT Rule is only valid for the .7. net? -
@Marv21 the redirect NAT rule is set up for the .7. net.
In the image below,SYNAPSE_LAN = .7.net.
-
@ibbetsion
dns_ok is 192.168.8.2 then - right? -
@ibbetsion
Where are you running this Dig command from?
A client from the 7 or the 8 Net?
