Whitelisting web destinations from container

RouterOS Containers
1

Greetings all - I have a couple existing Docker containers that I want to migrate to RouterOS. I have a Pihole container that handles DNS for internal clients, and then an Alpine container I built that runs the NextDNS client (since unfortunately they don’t support RouterOS natively) for DoH. The Pihole uses the NextDNS container as its upstream DNS. I only let the NextDNS container communicate outbound TCP 443 to the NextDNS servers, which is a handful of IP addresses. Since the Pihole isn’t responsible for DoH, I currently have it use a Squid proxy to get its adlist updates and all other web destinations are denied. Since Pihole isn’t proxy aware, I use Docker to transparently force proxy usage through its config.json file.

All of this I have running in a parallel environment on a RB3011, except for whitelisting the Pihole’s web traffic to the adlist servers which I can’t figure out how to do. I know I could simply NAT all traffic from the Pihole to the proxy, but since Pihole isn’t proxy aware I’m not sure if that would help. Wondering if others have tackled web filtering for their containers. Maybe a third container that acts as a transparent proxy?

2

What risk are you protecting against? PiHole suddenly goes evil?

3

Hi, thanks for responding. I just prefer to provision resources in accordance with least privilege. I know the Pihole only requires Internet access to the adlist servers to get its updates, so that’s what I give it. But I expected my first question would be “Do you need to run Pihole and NextDNS at the same time?” I know there is some functionality overlap there, but I like the flexibility and control that Pihole + NextDNS provide. I guess I’m just a belt and suspenders kind of person :smiley:

Anyway, too much OT. I guess if all else fails, I could control when the Pihole updates via cron and do a time-based firewall rule that opens TCP 443 at that time. But it’s clunky and I’m sure there’s a more elegant solution somewhere…?

4

If the updates happen over HTTPS or via a CDN, it’s likely more work than it’s worth regardless. Same basic problem as this.