I have a Pi-hole DNS server setup on my network. I have a guest network on an separate VLAN. The network has been up and running for some time, the Pi-hole is a new addition.

FW address list LAN =
192.168.1.0/24 (local)
192.168.2.0/24 (guest)

FW address list DNS_Server =
192.168.1.20

I am using 8.8.8.8, 8.8.4.4. on the router. I am specifying the Pi-hole as the DNS Server in the DHCP Server/Networks tab. It is the only one listed. I have a filter rule allowing the networks to the DNS server.

Edit: I should have mentioned that I am using conditional formatting on the Pi-hole to get individual post data. I am using a DHCP to DNS script to make this happen.

I am trying to force all hosts to use the Pi-hole DNS, i.e. stopping a client that has DNS hardcoded. This is the NAT rule I am using: Result - A client with 8.8.8.8 set for it's DNS on the guest network (192.168.2.0/24) redirects to the Pi-hole server works correctly. A client on the local network (192.168.1.0/24) times out. I feel like I am missing something very simple. I suspect I am creating a loop of some kind, just not sure why....

Further - I found these rules on the interwebs (https://www.reddit.com/r/pihole/comment ... ole_using/) but they work for me either, and I would prefer to be more granular anyway. I did, of course amend them with my addresses. This resolves the WAN as well, and masq rule in the link does not make sense to me either....
Any help appreciated. I feel like this is going to be a "I am an idiot" moment when somebody weights in and shows me the error of my ways. Thanks.

You are right in your post's topic: the only thing that is missing are hairpin NAT rules for requests from your main lan, that were intercepted by your existing rules.

@xvo is right,
The client was receiving an answer from your DNS server 192.168.1.20 while it was expecting an answer from 8.8.8.8... So you were getting a time out...
Adding the Hair Pin NAT rules, the DNS request is dst-Nated to your DNS server and at the same time the source IP is source Nated with the Routers IP. Then the DNS server will reply back to your Router, the router will then remove the DST and src NAT and your client will finally receive an answer as it was coming from 8.8.8.8...

You are right in your post's topic: the only thing that is missing are hairpin NAT rules for requests from your main lan, that were intercepted by your existing rules.

Code: Select all

add action=masquerade chain=srcnat src-address=192.168.1.0/24 dst-address-list=DNS_Servers dst-port=53 protocol=udp
add action=masquerade chain=srcnat src-address=192.168.1.0/24 dst-address-list=DNS_Servers dst-port=53 protocol=tcp

xvo - thanks so much for the feedback. This worked in a way.

I should have mentioned that I would like to use conditional forwarding that allows me to individual host data. On the Guest network your rules work as designed, but now all the traffic appears to be coming from the router not the source host. With out the masq rules a client on the Guest network with 8.8.8.8 DNS set, everything worked fine and I got the client DNS data.

For whatever reason, the local network will still not resolve with our without the masq rules. I think I am going to setup a test router (hex) and see if I can duplicate this and get around it....

I think if I put the DNS server in its own network this will work the way would like it to with conditional formatting in play. Running a redirect on the network the Pi-hole lives on seems to be the issue. Seems overkill I know....

On the conditional forwarding - I would like to eventually create some groups, kids for example, and do some different filtering.

@xvo is right,
The client was receiving an answer from your DNS server 192.168.1.20 while it was expecting an answer from 8.8.8.8... So you were getting a time out...
Adding the Hair Pin NAT rules, the DNS request is dst-Nated to your DNS server and at the same time the source IP is source Nated with the Routers IP. Then the DNS server will reply back to your Router, the router will then remove the DST and src NAT and your client will finally receive an answer as it was coming from 8.8.8.8...

Zacharias - thanks so much. This really helped get the packet flow right in my mind. You have a knack for making complex things easily understandable!

I wrote some additional detail in my response to xvo above. I would appreciate you feedback.

Cheers

On the Guest network your rules work as designed, but now all the traffic appears to be coming from the router not the source host. With out the masq rules a client on the Guest network with 8.8.8.8 DNS set, everything worked fine and I got the client DNS data.

That is strange indeed. It is one of the main disadvantages of hairpin nat and should be the expected behaviour, but for clients from 192.168.1.0/24, not from 192.168.2.0/24: the rules I posted can't match packets originated from 192.168.2.0/24.

I think if I put the DNS server in its own network this will work the way would like it to with conditional formatting in play.

You are right: putting PiHole on it's own separate network will eliminate the need for hairpin nat at all.
That's how I do it in my setup.

You can always post your NAT rules, maybe something is not right...

You are right: putting PiHole on it's own separate network will eliminate the need for hairpin nat at all.
That's how I do it in my setup.

@xvo
Thanks to you again - I have this up and running and it works perfectly.

On the "That's how I do it in my setup" virtuous comment, any other pieces of this from your setup you would recommend I implement? I suspect your setup is a bit more polished than mine... . Are you doing anything for failover? If you use it, any Pi-hole specific recommendations?

You can always post your NAT rules, maybe something is not right...

@Zacharias
Thanks for your reply. I only have 3 nat rules - the ones listed above and wan masq rule. To get the host name resolution in Pi-hole and make conditional forwarding work as it should putting the Pi-hole on it's own network is a solid approach. Getting name resolution for host filtering is important to me, or at least I think it is... I intend to configure different groups for filtering and tracking, i.e. kids, IoT, etc.. In the past I had a dedicated "family" vlan with opendns redirect configured. Worked well except for Sonos, chromecasts, and bonjour.... It was a PITA. I did get most of that working with avahi in large part thanks to you . I felt, however, like I was waiting for the next service to break or work intermittently. Keeping everyone on the same network and managing it with Pi-hole "feels" like a simpler solution.

Time will tell which approach is better one for me/us. Again, I appreciate your help and willingness to share on the forum.

Sure, am just curious why it does not work... there must be a mistake... but anyways it's great you found another working solution for you...

@xvo
Thanks to you again - I have this up and running and it works perfectly.

You are welcome

On the "That's how I do it in my setup" virtuous comment, any other pieces of this from your setup you would recommend I implement? I suspect your setup is a bit more polished than mine... . Are you doing anything for failover? If you use it, any Pi-hole specific recommendations?

Well, I don't really know what kind of advice do you expect from me - using Pi-Hole is quite straightforward, even with some complications like for example cloudflared DoH resolver.
As for failover, I guess the best way to achieve it would be running multiple instances in docker swarm, so they all are available at one ip address, but I didn't have a chance to try that yet.

@xvo
Thanks to you again - I have this up and running and it works perfectly.

Well, I don't really know what kind of advice do you expect from me - using Pi-Hole is quite straightforward, even with some complications like for example cloudflared DoH resolver.
As for failover, I guess the best way to achieve it would be running multiple instances in docker swarm, so they all are available at one ip address, but I didn't have a chance to try that yet.

No expectations - just looking for tips from the pros .

For failover, I may try a simple netwatch script to enable / disable a nat rule that redirects DNS to the router. If the Pi implodes it simply gets sent to the router. Of course if the service stops on the Pi the IP stack might still respond, so it is not perfect.

Thanks again to both of you - I appreciate the help!

For failover, I may try a simple netwatch script to enable / disable a nat rule that redirects DNS to the router. If the Pi implodes it simply gets sent to the router. Of course if the service stops on the Pi the IP stack might still respond, so it is not perfect.

Instead of netwatch you can schedule a script that will try to resolve some domain using Pi, to see if it is actually working as expected.
I use DUDE to monitor the availability of dns service from different parts of the network (among other things).
And it alarms me if something goes wrong.

For failover, I may try a simple netwatch script to enable / disable a nat rule that redirects DNS to the router. If the Pi implodes it simply gets sent to the router. Of course if the service stops on the Pi the IP stack might still respond, so it is not perfect.

Instead of netwatch you can schedule a script that will try to resolve some domain using Pi, to see if it is actually working as expected.
I use DUDE to monitor the availability of dns service from different parts of the network (among other things).
And it alarms me if something goes wrong.

That script is a great idea - I may test that as well.

I thought the dude was dead ..... That is something I should look into as well. Not enough hours in the day.

Thansk!

I thought the dude was dead .....

Despite the fact that it is neglected by developers, it still works more or less ok...