pi-hole
-
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?
-
@johnpoz & @stephenw10
Thank you, booth of you to take your time and try to explain an old man like me
So I did disable all my DNS rules in my LAN network. I only made one NAT rule: I know about the "Invert Match" but with this enable made my UniFi Controller Gen 2 Pro stop talking with 8.8.8.8. Now it only talks to PI-Hole IP (Am I right? :) )
But why? Is your local network hostile? Who would be intercepting or sniffing your dns traffic, other than you?Sometimes I am my own hostile in my own network
Indeed is more easy to get ride of all the rules, but, You know.. the feeling when your are loosing control. It's feels i'm loosing control over all the DNS request from IoT devices or other devices that are hard coded with other DNS servers. But I just need some conformation that my rule now is correct and Pi-Hole its doing his job with pfsense.
Is there a way I cant test this out? -
@MoonKnight said in pi-hole:
Is there a way I cant test this out?
Well just look at your pihole logs, do you see queries from these clients?
Do a query to 8.8.8.8 from your device, for something that only resolves locally.. Did it resolve? Then you sure didn't get them 8.8.8.8
example..
pi@pi-ntp:~ $ dig @8.8.8.8 nas.home.arpa ; <<>> DiG 9.11.5-P4-5.1+deb10u9-Raspbian <<>> @8.8.8.8 nas.home.arpa ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2478 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;nas.home.arpa. IN A ;; ANSWER SECTION: nas.home.arpa. 3600 IN A 192.168.9.10 ;; Query time: 0 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Tue Aug 29 11:49:56 CDT 2023 ;; MSG SIZE rcvd: 58 pi@pi-ntp:~ $There is no possible way 8.8.8.8 could resolve nas.home.arpa ;)
-
@johnpoz
Thanks :)Did a DIG from my UCK G2:
And Pi-Hole i found this:
So everything is OK?
I see my UniFi controller are sending lot of PTR request to 1.1.1.1.in-addr.arp and 8.8.8.8.in-addr.arp <.----- Normally ? It's already on Top Permitted Domains :D
-
@MoonKnight well as long as that fqdn you queried for is not actually a public domain, then clearly you were intercepted. Also I highly doubt you could get an answer back from any google server in 0 ms ;)
As to why your controller is doing PTR for those IPs - I have no idea, I don't see that in my pihole from my controller.
the query is in-addr.arpa right, you just left off a A, .arp would make no sense..
I can force the query to show up if I manually do a query for that
These are the sorts of things my controller is doing queries for
-
It's an public domain but not public :) Only for valid certificate via Acme. (Using my own public domain as man local domain) But there is now way you can access it from outside :)
Yeah I mean .arpa :)
I can see your controller are doing some crazy stuff too from your ubuntu server. I have the hardware version of the controller from UniFi, probably that's why so much noises, hmmm
You can see when I was trying to push my LAN network to use PI-Hole
Still have 2-3 more VLANs to add.
-
@johnpoz & @stephenw10
I am baaaccckkk
Sorry to bring this up again. Just woundring about the NAT rule I made. Should I select "Create new associated filter rule" in the Filter rule association? Ore just use NONE ?
-
@MoonKnight normally you would allow your port forward to create the firewall rule. Only thing you really need to do is make sure that rule is in the correct spot on your wan.. Rules are evaluated top down, if you had some rule above your new created one that would block access then your port forward wouldn't work.
-
@johnpoz Thats true, but my rule is an redirect for DNS to LAN network, in this case not WAN :)
-
@MoonKnight same situation.. Just different interface is all.
-
@johnpoz Thank you very much :)
-
M MoonKnight referenced this topic on
-
@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.
I'm having the exact same problem here and was able to apply the same SNAT workaround done by @AndyRH in one of his posts here. I'm curious on your solution though. If the NAT IP in your DNAT rule is 127.0.0.1, how does it redirect it to the pihole that's on the same subnet as the client? Is it because unbound in pfsense is set to forward to that same pihole server?
-
@kevindd992002 said in pi-hole:
Is it because unbound in pfsense is set to forward to that same pihole server?
Yeah that would work, but then your pihole doesn't know the client IP.. this is why its best to just point your client directly to the pihole IP, especially if on the same network.
You could always put your pihole on different vlan than any of your clients.. But in another thread around here talked about little point in doing redirection if your end goal is clients using pihole. Its better to just point the clients directly to pihole so pfsense is not in the loop when it doesn't really need to be.
