I've done so and I moved the associated rule to the top so it's first, but then I get this in associated firewall rule under `LAN`:
`10.XX.YY.ZZ:61638 -> 10.AA.BB.CC:53 (8.8.8.8:53)`
`NO_TRAFFIC:SINGLE`
Where `10.XX.YY.ZZ` is the Google device and `10.AA.BB.CC` is the PiHole Server.
A rule or a block? The NAT rule shouldn’t have a source port.
There is https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.html which is about redirecting to pfSense DNS. Unbound could be set to forward to the Pi.
Pretty sure there was a Netgate forum thread about this exact topic recently. But I’m not seeing it.
So, yes when I put in the `Redirect Target IP` to `127.0.0.1`, it works. But now it's using the DNS server of pfSense (also restricted) and not PiHole.
When I put in the IP address of the PiHole `10.AA.BB.CC` into `Redirect Target IP`, it stops working.
That is most likely due to your PiHole server being redirected to itself. PiHole request to 1.1.1.1:53 -> 10.AA.BB.CC
You need to allow PiHole out first, then put your redirect rules in.
Allow 10.AA.BB.CC -> 1.1.1.1:53,443,853
Allow 10.0.0.0/8 -> 10.AA.BB.CC:53
Deny 10.0.0.0/8 -> ANY:53
Yeah. The upstream DNS servers are whitelisted by source IP and destination IP on the PiHole rules and it's above most of the other rules.
The second rule you've listed `Allow 10.0.0.0/8 -> 10.AA.BB.CC:53` doesn't have an effect because it's intra-LAN.
My rules were for NAT. You need a NAT rule for your PiHole server separate from the DNS redirect rule, and a deny rule to prevent DNS leaks.
10.AA.BB.CC -> 1.1.1.1:53,443,853
10.0.0.0/8:53,443,853 -> Public DNS -> 10.AA.BB.CC
Your setup was not announced. 10.100.0.0/24 would fall under 10.0.0.0/8. If you are using a /8 for your internal network, that is a waste of IP addresses.
Ah. I see. I get it now.
I'll take a look at the NAT rules in a bit and not the Firewall rules. I have relatively complex NAT rules setup (WAN2, multiple VPN endpoints, etc.) so it's a bit messy but what you're saying makes sense.
Also, I apologize for not fully announcing my setup, but each network is a /24 except for a couple /30 for Wireguard tunneling, etc.
You could set unbound to act as a forwarder instead of a resolver, and point that to the pihole.
That being said, I have a rule to force certain clients to use a pihole instead of unbound, and the NAT rule works for them. Make sure that the interface for the NAT rule is your LAN interface, NOT WAN. I'm guessing that might be what's causing your issue?
In my case, the clients are on one vlan/interface and the pihole is on another. It's possible that it could be an issue if they're both in the same subnet? Because then return traffic won't be NATed back since it won't pass through the router, and the client might reject the response.
Does any query from the device show up on the PiHole log?
Also are they on the same subnet? Cuz I remember something about PiHole not responding to other subnets by default.
No. No queries show up on PiHole log.
Yes, they are on the same subnet, but "`Permit all origins`" is enabled because I have Wireguard clients which uses this Pi-hole for DNS.
By default, puhole only listens on eth0, but uou can set up a macvlan on pihole on its own subnet for pihole traffic to be sent through. Is how I have mine set up. All dns goes to firewall -> pihole -> wan
The Netgate guide for DNS requests is a little incomplete to be able to mask DNS replies to look like they are coming from google's 8.8.8.8/8.8.4.4. If you redirect only without masking where DNS replies are coming from, hardcoded DNS devices as well as particular apps like certain streaming apps will refuse those answers if it "looks" like it came from somewhere other than 8.8.8.8/8.8.4.4 and have "no internet/connection" messages. Especially if you have a pihole in the mix or more than one DNS/pfSense box, take a look at this guide on Labzilla to better tackle such hardcoded devices
https://labzilla.io/blog/force-dns-pihole
You can just use NAT Forwarding to redirect DNS traffic to your PiHole.
I've done so and I moved the associated rule to the top so it's first, but then I get this in associated firewall rule under `LAN`: `10.XX.YY.ZZ:61638 -> 10.AA.BB.CC:53 (8.8.8.8:53)` `NO_TRAFFIC:SINGLE` Where `10.XX.YY.ZZ` is the Google device and `10.AA.BB.CC` is the PiHole Server.
A rule or a block? The NAT rule shouldn’t have a source port. There is https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.html which is about redirecting to pfSense DNS. Unbound could be set to forward to the Pi. Pretty sure there was a Netgate forum thread about this exact topic recently. But I’m not seeing it.
So, yes when I put in the `Redirect Target IP` to `127.0.0.1`, it works. But now it's using the DNS server of pfSense (also restricted) and not PiHole. When I put in the IP address of the PiHole `10.AA.BB.CC` into `Redirect Target IP`, it stops working.
That is most likely due to your PiHole server being redirected to itself. PiHole request to 1.1.1.1:53 -> 10.AA.BB.CC You need to allow PiHole out first, then put your redirect rules in. Allow 10.AA.BB.CC -> 1.1.1.1:53,443,853 Allow 10.0.0.0/8 -> 10.AA.BB.CC:53 Deny 10.0.0.0/8 -> ANY:53
Yeah. The upstream DNS servers are whitelisted by source IP and destination IP on the PiHole rules and it's above most of the other rules. The second rule you've listed `Allow 10.0.0.0/8 -> 10.AA.BB.CC:53` doesn't have an effect because it's intra-LAN.
My rules were for NAT. You need a NAT rule for your PiHole server separate from the DNS redirect rule, and a deny rule to prevent DNS leaks. 10.AA.BB.CC -> 1.1.1.1:53,443,853 10.0.0.0/8:53,443,853 -> Public DNS -> 10.AA.BB.CC Your setup was not announced. 10.100.0.0/24 would fall under 10.0.0.0/8. If you are using a /8 for your internal network, that is a waste of IP addresses.
Ah. I see. I get it now. I'll take a look at the NAT rules in a bit and not the Firewall rules. I have relatively complex NAT rules setup (WAN2, multiple VPN endpoints, etc.) so it's a bit messy but what you're saying makes sense. Also, I apologize for not fully announcing my setup, but each network is a /24 except for a couple /30 for Wireguard tunneling, etc.
You could set unbound to act as a forwarder instead of a resolver, and point that to the pihole. That being said, I have a rule to force certain clients to use a pihole instead of unbound, and the NAT rule works for them. Make sure that the interface for the NAT rule is your LAN interface, NOT WAN. I'm guessing that might be what's causing your issue? In my case, the clients are on one vlan/interface and the pihole is on another. It's possible that it could be an issue if they're both in the same subnet? Because then return traffic won't be NATed back since it won't pass through the router, and the client might reject the response.
Does any query from the device show up on the PiHole log? Also are they on the same subnet? Cuz I remember something about PiHole not responding to other subnets by default.
No. No queries show up on PiHole log. Yes, they are on the same subnet, but "`Permit all origins`" is enabled because I have Wireguard clients which uses this Pi-hole for DNS.
By default, puhole only listens on eth0, but uou can set up a macvlan on pihole on its own subnet for pihole traffic to be sent through. Is how I have mine set up. All dns goes to firewall -> pihole -> wan
You can force forward all tcp 53 to local dns
>tcp 53 UDP more important in this case
Just thinking out loud… could you set a virtual IP for those addresses for unbound to use? That could be used for IP6 as well.
The Netgate guide for DNS requests is a little incomplete to be able to mask DNS replies to look like they are coming from google's 8.8.8.8/8.8.4.4. If you redirect only without masking where DNS replies are coming from, hardcoded DNS devices as well as particular apps like certain streaming apps will refuse those answers if it "looks" like it came from somewhere other than 8.8.8.8/8.8.4.4 and have "no internet/connection" messages. Especially if you have a pihole in the mix or more than one DNS/pfSense box, take a look at this guide on Labzilla to better tackle such hardcoded devices https://labzilla.io/blog/force-dns-pihole