pi-hole
-
@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.
-
@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.
Well, that's what I already do. I point all my clients to my Adguard Home server. The redirect is there for when a client does not respect the DNS server that's handed to them by the DHCP server in pfsense (which is my Adguard server's IP) and they try to use some other DNS. And you said that to do that, you need to use 127.0.0.1 as the redirect IP, right? What does that achieve? Does it redirect that client to unbound in pfsense and ultimately to the pihole server? This is what I'm curious about as I don't understand it.
-
@kevindd992002 so yeah if your client is on the same network as what your redirecting too.. you can run into the client complaining hey the answer is coming from someone I didn't ask.
When you redirect it to loopback (127.0.0.1) unbound - then does a query to what its forwarded to, be that adguard or pihole or any other ns you have set in unbound to forward too. It would ask this NS via the pfsense IP, it would get an answer and then send that back to the client.
When you redirect it to this other NS directly, the ns says oh 192.168.x.x asked me - let me send that answer to it, which is when they are the same network is when you run into the hey some other server answered me problem.
So you can use the loopback redirection, so you don't know in the other NS log who actually asked, because to the NS pfsense asked. If you redirect to the NS IP, it would know who asked, but you could run into problems with asymmetrical response.
What solution is best would be up to your specifics - if you want to redirect say 8.8.8.8 to go to your NS and also know on the NS which client asked I would put the NS on its own network, so you never run into the issue asymmetrical problem.
-
@kevindd992002 so yeah if your client is on the same network as what your redirecting too.. you can run into the client complaining hey the answer is coming from someone I didn't ask.
When you redirect it to loopback (127.0.0.1) unbound - then does a query to what its forwarded to, be that adguard or pihole or any other ns you have set in unbound to forward too. It would ask this NS via the pfsense IP, it would get an answer and then send that back to the client.
When you redirect it to this other NS directly, the ns says oh 192.168.x.x asked me - let me send that answer to it, which is when they are the same network is when you run into the hey some other server answered me problem.
So you can use the loopback redirection, so you don't know in the other NS log who actually asked, because to the NS pfsense asked. If you redirect to the NS IP, it would know who asked, but you could run into problems with asymmetrical response.
What solution is best would be up to your specifics - if you want to redirect say 8.8.8.8 to go to your NS and also know on the NS which client asked I would put the NS on its own network, so you never run into the issue asymmetrical problem.
Ahh, yeah, I completely understand you. In fact, it's the same exact thing I explained in my post here: https://forum.netgate.com/post/1123048
And yes, just as I thought, in your solution you were pertaining to when unbound is set to forward to any other DNS server and not when it's set as a resolver. Ok, I think I got your whole point already. Thanks for the explanation!
-
TLDR;
We're using pi-hole for DNS, and let pfSense do all the DHCP, routing and firewalling tasks.
This solution suits our use case, and has been working well for a long time.
YMMV.
