pi-hole
-
I'm not able to setup pfBlockerNG and looking for an easier solution.
Just found out this interesting project: https://github.com/pi-hole/docker-pi-hole/#running-pi-hole-docker
Any plans to add docker add-on on pfsense plus?
-
To make this work within this use case:
- ISP
- pfsense
- LAN hostwith pihole
I've setup in pfsense System > General Setup:
- DNS servers LAN hostwith pihole
- Resolution behavior: use remote DNS server, ignore local
-
@Summer I highly doubt docker support will be added to pfsense.
I use pihole myself, and pfblocker as well.
If you want to run pihole on some box on your network, do so.. Just point your clients to the pihole, and then have the pihole forward to pfsense for dns.
-
What part of pfBlocker are you having a problem with?
Running pi-hole on a.... pi seem like an obvious solution.
You could probably run it under bhyve if you really wanted to. Setting that up would b significnatly more complex than pfBlocker though.
Steve
-
@johnpoz actually with the pfsense config on DNS general there's no need to touch clients config.
My concern was if pi-hole host goes down, but pfsense would go to next DNS server entry.
-
S Summer referenced this topic on
-
-
My concern was if pi-hole host goes down, but pfsense would go to next DNS server entry
I am not sure you understand how clients behave with more that one DNS entry. It is not primary and secondary. It is try one then quickly try the next one. For consistent results all the DNS servers need to answer the same.
While I am a fan of Pi-Hole, pfBlocker is about the same difficulty, frequently referred to as easy.BTW, Pi-Hole redundancy is to have more than 1 Pi-Hole.
-
@AndyRH thanks I'll try to understand this better.
A client with it's DNS as pfsense LAN ip, try to reach a domain that is blocked on pihole wich is the main DNS of pfsense.
It seems to work fine, why it isn't supposed to work?
-
why it isn't supposed to work?
nobody said it wouldn't work.. But not really optimal sort of flow. Lets say something is blocked in pihole.. it normally hands out a ttl of 2 seconds for this block..
Your client asks pfsense, pfsense asks pihole, pihole answers with 0.0.0.0 with ttl of 2 seconds. pfsense hands this back to client. 3 seconds later client asks again, once again pfsense has to ask pihole, cycle repeats.
if you had client directly asking pihole, pfsense unbound is not involved..
Why include pfsense in this sort of thing? Would seem like better flow if client just directly asked pihole, and then pihole forwards to pfsense. you could then have unbound either resolve or forward..
Also if you ask unbound first, then pihole - how does pihole know who is asking.. Your reports are just going to show pfsense IP in all your pihole logs.
if your clients directly ask pihole, pihole eye candy and reports can show you what each client is asking for, etc..
I can click into specific client and see exactly what a client asks for, what is blocked what is answered, etc. If all your seeing is pfsense IP for all your queries - pretty much defeats the purpose of all the "eye candy" ;) If you have something asking for something specific - how do you know which client is doing it?
-
@Summer I think maybe I was not clear.
A client with 2 DNS entries, .1 and .2. It will try .1 and wait a short time for a reply then try .2. It is possible for .2 to reply first.
Based on the question, it sounds like you have the clients pointed at pfSense and pfSense pointed at PiHole, PiHole pointed to a public DNS server. I feel that method has too many points to troubleshoot (Others may disagree). I went with redundant PiHoles and supply that list to the clients. pfSense does its own thing and just goes to a public DNS server.
There are very many ways to do DNS with blocking. Of the many ways there is more than one good solution.
-
@Summer I highly doubt docker support will be added to pfsense.
I use pihole myself, and pfblocker as well.
If you want to run pihole on some box on your network, do so.. Just point your clients to the pihole, and then have the pihole forward to pfsense for dns.
Hi @johnpoz
May I ask you, could you please share your setting of how you have setup your pi-hole and pfsense?
Only if you have time, would be nice with some picture of your settings of pfsense and pi-hole.
I'm planning to try out pi-hole, but not sure about all the setting in pi-hole and some in pfsense.
I also using DNS Resolver with DoT. And Quad9 dns servers.Thanks in advanced
-
@MoonKnight I don't have anything special setup in unbound, it just resolves.. Pretty much out of the box in that respect.. I do have some other settings like serve-zero, prefetch, qname min, etc. But none of that has anything to do with how pihole works. Or what it does, to pfsense pihole is just another client.
Pihole I have setup to forward to a pfsense IP.
My clients get handed the pihole IP in dhcp, 192.168.3.10, the 192.168.3.0/24 is my "dmz" network if you will.. Its just really another segment. I called it dmz just because at one point I had another pi in this segment that was serving ntp to the internet via being a member of the ntp pool. I have shut that down, but haven't bothered ever changing what I call that interface ;) Even though I have nothing in that network that is exposed to the public internet any more. I could prob rename it to pi-segment or something.. There are 3 pi's in that network.. The rules are locked down for that segment, so if I was going to fire up something I exposed to the public internet, it would be isolated from the rest of my networks.
What you have unbound do, be it resolve, forward, forward via dot, etc has no bearing on who is asking it be it just a normal client on your network or pihole asking for some other client that asked it.
-
@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?
