I have been trying very hard to get this to work myself (without seeking help here), but, alas, I'm stuck.

I have a heX acting as my main environment's router (192.168.2.2).

I have a spare RB5009 that I'm using to learn on (192.168.2.50). It's not performing any functions whatsoever and is connected to the LAN with a single cable in port 2 connected the main switch on the LAN.

On the RB5009, I set up:

1) a bridge named 'docker' (type bridge)
2) veth1 with 10.0.0.2/32 address and 10.0.0.1 gateway
3) address lit 10.0.0.1/24 interface docker
3) pihole container with interface of veth1 (envs_pihole, etc.)
4) NAT dst-nat rule pointing 192.168.2.50:4443 to 10.0.0.2:80
5) route 10.0.0.0/24 with gateway docker

The pihole container status is 'running' and I can manage it at 192.168.2.50:4443

From inside the RB5009 I can ping 10.0.0.1 and 10.0.0.2

From inside the hex I can ping 10.0.0.1 and 10.0.0.2

From a Windows PC on the LAN (192.168.2.22) I can ping 192.168.2.50 but cannot ping 10.0.0.x

So I thought there was a routing issue, and I added to the heX a NAT dst-nat rule with dst address of 10.0.0.0/24 with 'to address' of 10.0.0.1 and then I tried 192.168.2.50. Neither gave the correct results.

When I point the Windows PC's DNS setting to 10.0.0.2, DNS requests are not getting to the pihole container.

My guess is that the heX is seeing the packets originating from the Windows PC and destined for 10.0.0.x and doesn't know what to do with them.

I tried adding a route to the heX with dst address 10.0.0.0/24 with gateways of 192.168.2.50

Can someone let me know what I'm doing wrong?

Thank you.

HeyHey,

I see some problems with your setup, but the overall picture is not clear yet so correct me if I got it wrong.

The veth1 has an /32 address, I assume it should be available inside your 'docker' network/bridge then you might want to change it to /24.
/32 means it's just an IP address without any subnet, and I think the docker itself won't have internet/network access.

If you have created the 10.0.0.1/24 network on the RB5009, how is this network bridged/connection on the HeX.
With your description (and I can be wrong) I am not sure if pinging 10.0.0.2 is actually returning any data from your RB5009 or docker container.

Please note that DNS requests use the UDP/TCP port 53 and the default docker/container guide isn't giving details that infact you need to forward those requests aswell before you can use your pihole outside of the RB5009 device.

Another note; the 192.168.2/24 IP-range and 10.0.0.0/24 are 2 different networks and to be able to talk to each other an router with an valid route is required.
So if you want to reach the 10.x range from your Windows PC then the default gateway (I assume your HEX) should have a route towards it.
But giving your description you probally just want to open/forward the DNS request & http (port 80) with an dst-nat rule and your setup.

Hoping this helps a bit

Thanks very much for the help.

This is all brand new to me.

I changed veth1 to 10.0.0.2/24. I had thought that veth1 was treated a single port with a single ip -- hence the/32.

I've made some more discoveries:

The reason I was able to ping from the heX to the RB5009's container, but not from a PC on the LAN to the RB5009's container, appears to be because the heX needs a FORWARD rule to accept all dst traffic for 10.0.0.0/24. I used torch and packet sniffer to determine where packets were reaching, and logging of rules to see where packets were being dropped. I created that rule and I can ping 10.0.0.1 and 10.0.0.2 from a PC on the LAN.

The next problem was that DNS requests appear to work fine from within the RB5009 (using the ping tool with a FQDN instead of an IP), but not from a PC on the LAN.

I haven't figured out why, but I did discover that if I configure the PC on the LAN to use the RB5009's ip address (192.168.2.50) as the DNS server it works. (DNS is configured on the RB5009 to Allow Remote Requests).

I suspect I need another firewall rule -- I'm working on it.

The beauty of what you're trying to do is that there are a few ways you can do it to make it work. All of them are fine, none are wrong, but exactly how you implement it will depend on the layers of complexity you're comfortable with. You're already so close.

- Method 1: Allow all local hosts to access the Pi Hole container directly.

If the hEX is acting as your default gateway for all the PC's to the rest of the Internet, then yes, it needs to have a static route for 10.0.0.0/24 over to 192.168.2.50 where that subnet lives (on the RB5009). You can use NAT to do that, but it's cleaner/more efficient not to if you're staying within your own LAN. You may also need a firewall rule that allows forwarding for that subnet and possibly a NAT rule that "accepts" that subnet from 192.168.2.0/24 to 10.0.0.0/24 (or 192.168.0.0/16 to 10.0.0.0/8 to allow for other tests you might do in the future) before any masquerade or src-nat rules.

- Method 2: NAT from the RB5009 to the container.

Alternatively, you could set up more port forwarding rules on the RB5009 to have all DNS queries go to the Pi Hole directly by NATting TCP and UDP ports 53 (similar to the 4443->80 run you've already created).

- Method 3: RB5009 or hEX as DNS cache/forwarder.

As you figured out, the RB5009 is already forwarding DNS queries on behalf of any PC configured to use it as a DNS server. If you haven't already, configure the RB5009 to use the Pi Hole container's IP as its only upstream DNS server on the DNS settings page, leaving "allow remote requests" enabled.

If the hEX is already the DNS server for the whole network, you could configure it to use to the Pi Hole's IP as its own upstream DNS server, or to use the IP of the RB5009 (in either NAT or DNS forwarding mode). You likewise could change the hEX's DHCP server settings to hand out the preferred IP (either Pi Hole directly or RB5009) to local hosts.

One reason you might choose to use one of the MikroTiks' DNS resolvers instead of having the PC's talk to the container directly (or via NAT) is so you can create static DNS entries in that router and not have to have them in the Pi Hole container, which is great for testing, especially if the container's unavailable for any reason.