pi-hole
-
@johnpoz
Thank you very much. I'm going to try this out later
-
@johnpoz thank you for detailed explanation, it make sense.
Just last doubt, setting up a NAT rule on pfsense to redirect incoming DNS traffic to pi-hole host should do the same job than setting up dns on each client?
-
Yes you can redirect DNS if clients are hard coded to use something. Some device always use 8.8.8.8 for example.
https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.html
That shows redirecting to pfSense but it could be an external server like a Pi-hole.
Steve
-
@Summer keep in mind a redirection to pihole, if the clients are on the same network could lead to clients not liking the answer coming from a different IP then what they sent too.
that is from client on my 192.168.3 network... Now if the client is on a different network than the pihole, they wouldn't know that it was redirected.
Also a redirection doesn't get rid of the non optimal flow pattern I gave as example where pfsense is involved in the traffic for no good reason. While it can get your pihole to see the IP of the client for the eye-candy. You still have the non optimal flow of traffic having to go through pfsense when there is no point to doing that..
Clients should just point to pihole.. If you want to also redirect traffic when they try and use some other dns - ok that is good, but the redirection should be done using 127.0.0.1 as the redirection. So even when client is on the same network as pihole it doesn't know it was redirected to some other IP..
While the redirection works now even for clients on the same network as the pihole, pihole now doesn't know the client IP that was asking.
-
This is the detailed write-up on how I setup redirect to PiHole that I posted a while back and still use. The clients do not complain when trying to talk to 8.8.8.8 and are really talking to 192.168.42.126.
https://forum.netgate.com/topic/156453/pfsense-dns-redirect-to-local-dns-server?_=1663853296484
-
https://forum.netgate.com/topic/156453/pfsense-dns-redirect-to-local-dns-server?_=1663853296484
yeah your using a source nat when the pihole is on the same network as the client, not really needed unless the client is on the same network as the pihole. But it is a work around for sure for that scenario, where clients might try a different ns other then what they pointed too.
Curious why your response time was 70 ms when everything was local, when you tried 1.2.3.4 - which is a good test for redirection ;) And while you can fool just dumb clients, if human tried that they should know right away they are being redirected..
Notice in my test the time was 0 ms, which would be typical for local resolution of a cached item, be it you forwarded to pihole or not.
A bit off topic - but good info none the less. 2 easy tests for redirection. Try something that for sure is not a NS, like your 1.2.3.4 test - if you get an answer you know some dns shenanigans is being done.. Another way is to query directly an authoritative NS for something - if you do not see the auth flag, then you know you have been redirected as well.
So there 3 things that should stand out to anyone in this 2nd query that something is off in the response. One there is no aa flag, which if you did actually talk to the authoritative ns for a domain should be there. 2nd is the ttl is not full, when you talk to an authoritative ns the ttl will always be the full ttl.. And 3rd a response time that doesn't make sense for talking to some NS out on the internet.. In my case its 0, but it could also just be too good to be true.. Ie your only really talking to some ns in your isp network. and not the actual authoritative ns for some domain that could be on the other side of the planet.
Another thing you can spot cname resolution. If you actually talked the auth ns for domain, and the record you looking for is a cname that points else where, all you will get back is the cname, if you were redirected you will normally get the full resolution of that cname as well.
-
Curious why your response time was 70 ms
I never noticed the time. Guessing, I would have to say it was not cached and the response from the internet slow. This weekend when I have time I will poke around and make sure it is not a FW delay.
A problem I did not notice until yesterday is pfSense round robins the DNS server it redirects to, I had 2 of 3 down and response from DNS was unreliable. I also discovered a phone game is using a hard coded DNS server different from the phone settings. Kind of a mixed bag. Things not redirected worked just fine. -
@johnpoz
I just fall of the rock here :)
I got my pi-hole working on one of my vlans, VL30, the pihole is there. I manage to redirect VL90 poiting to pihole at VL30. (different subnet)
This this NAT rule:
I made the same rule only for my LAN network, like this:
LAN use this subnet: 10.10.10.0/24
VL30 use this: 10.10.30.0/24 <------ Pi-hole IP: 10.10.30.200
VL90 use this: 172.16.90.0/24So the question is. Is this the right way to do it. My PI-Hole points to pfsense IP, so pfsense can to the resolving and forwarding to Quad9 IP.
And this is from the query log, log from my UniFi G2 Pro controller. I see it reacting out for google dns 8.8.8.8
I have a redirect rule in pfsense for preventing my IOT devices to talk to other dns then only the one pfsense forwaring to, in this case Quad9.
Maybe I'm terrible wrong, but it is a way to check that?
-
@MoonKnight I wouldn't use the ! rule myself..
-
@johnpoz
If i remove ! noting hits pi-hole from my LAN network.EDIT:
Looks like I had to disable all my "DNS" rules to get i working with Pihole.
All inside the red circle i have to disable
-
You need at least some redirect rule to catch anything that's hard coded to use some other DNS server. It doesn't have to be an inverted match rule, it could just match all DNS traffic.
-
@stephenw10
Hi,
Well I believe the both rules in the middle are the ones that are redirecting everting else to DNS, The once with 127.0.0.1. So if I change 127.0.0.1 to pi-hole IP, it should be okay then?
And remove the first rule (pi-hole) but the problem could be the second and third rule (destination = LAN address) -
Well those are firewall rules. You'd need to make that change on the NAT rules.
-
This is my NAT rules for redirect other DNS back to 127.0.0.1 (inside red circle)
The rule in the top is pi-hole rule I made to redirect all DNS to pi-hole. I hade to disable second rule to make my LAN hit pi-hole.
--- 24.11 ---
Intel(R) Xeon(R) CPU D-1518 @ 2.20GHz
Kingston DDR4 2666MHz 16GB ECC
2 x HyperX Fury SSD 120GB (ZFS-mirror)
2 x Intel i210 (ports)
4 x Intel i350 (ports) -
Are you passing the pihole IP to client to use for DNS via DHCP anyway?
That second rule should do nothing if the first rule is enabled. They both match the same traffic.
-
@stephenw10
Yes, I have setup DNS in the DHCP server, so all my clients in LAN got the Pi-Hole IP. -
@MoonKnight that second rule has nothing to do with anything.. And should never work with any sane dot client.. One of the major points of dot is to prevent mitm sort of dns tampering.. The dot server would present a cert, and that cert name needs to match the CN of the dot server your talking to, and it should be signed by a CA the dot client trusts.
If some dot client doesn't validate this - then is pretty useless in the sense of what dot is suppose to help accomplish, secure your dns traffic, and actually validate your talking to the dns you want to talk too.
BTW, I am not really aware of any common user "client" that uses dot, that is more a server thing for forwarding, clients normally use doh vs dot. But the same thing comes into play - part of the whole use of tls and certs is validation of who your talking too, redirection to some other thing would defeat part of the reason someone might want to use those protocols.
Unless you knew what dot server some client was wanting to talk too, and setup the certs to present that name to the client, and signed that cert with a ca the client trusts that sort of redirection should fail - if the dot client was actually checking, if the dot client doesn't check - its a pretty shitty client.
-
@johnpoz and @stephenw10
Damn, so all my lovely DNS rules are wrong?
All I wanted was to use DoT and redirect all hardcoded devices to use pfsense.
I see lot of devices are using other DNS servers. I don't want that, so I was thinking maybe my DNS rules would prevent that.
I can see in the pfTOP that all, I think all of my devices hits my pfsense IP and 127.0.0.1 on port 53 and 853. And of course Quad9 DNS server I have on my pfsense.
I can't see any traffic on dns 1.1.1.1 or 1.0.0.1 or 8.8.8.8 or 8.8.4.4 etc in the pfTOP. And i do have lot of Iot devices. So i believe my rules are working, but not so sure if I enable Pi-Hole and i have to disable some of my rules. :)--- 24.11 ---
Intel(R) Xeon(R) CPU D-1518 @ 2.20GHz
Kingston DDR4 2666MHz 16GB ECC
2 x HyperX Fury SSD 120GB (ZFS-mirror)
2 x Intel i210 (ports)
4 x Intel i350 (ports) -
Yes, you can't redirect DoT because the authentication will fail. Clients can still use DoT to pfSense, or the PiHole, directly though.
-
@MoonKnight you can for sure redirect typical dns on udp/tcp 53.. But dot or doh, even if you could redirect dot.. If the client is sane and validates the cert presented to it by the dot server your redirection wouldn't work.. Unless where you redirected it to matched up with the CN the dot client was wanting to talk to, and it trusted the CA you used to sign the cert.
Doh would have the same sort of problem with the client trusting the cert, but you can not use port to do redirection because doh hides itself on port 443, which the normal https port that pretty much everything on the internet uses..
I pretty much just block all known doh servers IPs, and dot I just block as well.. But that is much easier because it is suppose to use port 853.. And not try and hide itself in my normal https traffic.
As to internally using dot or doh on your network - sure you can do that.. But why? Is your local network hostile? Who would be intercepting or sniffing your dns traffic, other than you?
