I have started running pihole as a container on my MT box - all works well re. DNS serving and ad blocking. However, I noticed that the pihole has been receiving a lot of DNS requests from outside my LAN network - at one point quite a deluge.
I put some drop rules in the firewall and attempted a few other semi-random fixes (like restricting the VETH range), but I still get external IP addresses that appear in the pihole query logs as DNS clients.
Am I misunderstanding what is going on here - either in the DNS clients appearing to come from outside the network or failing to block WAN-side requests?
Config posted here. The container is on a separate IP range, so there are some rules for bridging that with the LAN. aargh.rsc (10.4 KB)
D
In your WAN client you tell the router to use ISP DNS ?? /interface pppoe-client
add add-default-route=yes disabled=no interface=“Port 8 - WAN” name=Vodafone
service-name=“Vodafone PPPOE” use-peer-dns=yes user= XXXXX@broadband.vodafone.co.uk
Then you state that IP DNS should be from outside the router but use DOH. /ip dns
set allow-remote-requests**=yes** cache-size=8192KiB max-concurrent-queries=1000
max-concurrent-tcp-sessions=2000 servers=1.1.1.3,1.0.0.3 use-doh-server= https://family.cloudflare-dns.com/dns-query verify-doh-cert=yes
You have some static settings that work in conjunction with this assuming to get get an initial connection to the DOH servers after that its encrypted. So not quite sure why you hgave the 1.1.1.3 or 1.0.0.3 in the IP DNS settings??
Then you state you want users to use pi-hole for DNS… add action=accept chain=input comment=“Allow DNS request for Container - UDP”
dst-port=53 in-interface=dockers protocol=udp
add action=accept chain=input comment=“Allow DNS request for Container - TCP”
dst-port=53 in-interface=dockers protocol=tcp
This rule is good as it allows user access to dockers for pi-hole usage…
add action=accept chain=forward comment=“Docker forward rule” in-interface=
“Local Bridge” out-interface=dockers
Not sure if your dst-nat and src-nat rules are quite right, very confusing…
In the previous thread Normis suggested that the best way to have DoH and use my preferred upstream DNS server (1.0.0.3, etc.) was to make the router the upstream DNS server for the pihole using DoH (the default pihole image doesn’t do DoH). This worked, and he seems to know what he’s talking about, so I left it like that.
Does that explain the DNS setup?
It’s easy for a relative newbie, like me, to get confused by the NAT rules. I guess my first priority is to make sure I’m not doing anything unsafe or insecure, then to make sure I’m not enabling WAN dns requests (if that is even a separate thing).
Does that help? Do you think I need to change any of the rules to protect the router/prevent external DNS requests?
Actually, still getting the odd foreign DNS client request. I don’t understand how that could happen… Either WAN-side DNS requests are possible, or they aren’t. Or there is some weird pihole pass-through bypass situation going on.
I’m fairly certain that the NAT rules are not quite right.
I can confirm that I am getting lookups from WAN. Bizarrely, a Drop Rule on the input chain for the IP range that worries me does detect any traffic, but an equivalent drop rule on the forward chain does.
Very easy to check, connect computer to other network (eg. mobile hotspot) and set on it DNS address manually to your public WAN address and see what happens. If you can resolve hosts on that computer then your DNS is exposed to WAN.
The only thing that smells to me are these two rules… (input chain clearly blocks dns inquiries to the router itself). add action=dst-nat chain=dstnat comment=
“Force any UDP DNS queries that aren’t to pihole to go to pihole”
dst-address=!172.17.0.2 dst-port=53 protocol=udp src-address=!172.17.0.2
to-addresses=172.17.0.2
add action=dst-nat chain=dstnat comment=
“Force any TCP DNS queries that aren’t to pihole to go to pihole”
dst-address=!172.17.0.2 dst-port=53 protocol=tcp src-address=!172.17.0.2
to-addresses=172.17.0.2
Make sure that for destination NAT you include something in those two rules that clearly make entry to those rules from the LAN side of the router.
in-interface-list=LAN as one criteria, to ensure that nothing external to the router creeps in!!!
To use it only locally you don’t need port dstnat rules and for srcnat masquerade you already have global masquerade rule for out intf. WAN, just create firewall forward from LAN to container and vice versa if you want to container access LAN. Also just block any forward from WAN to !LAN. Container bridge (dockers) shouldn’t be in LAN interface list in this case.
If I change the in interface to the local bridge (which is not quite what you suggested “in interface list”, but I hope is equivalent) then the forwarding stops and a drop rule at the top of the filter rules starts to register the offending traffic. I assume I don’t explicitly need this rule (because I block anything else later), but it has definitely changed the behaviour to something more understandable.
No problem, I just passed you config quickly and did not examine all firewall rules but noticed nat rules which you don’t need. Firewall rules suggestion was just a tip how to approach firewall configuration in this case.
The NAT rules are there as I use the router as the upstream DNS server to the pihole but advertise the router’s address as the DNS in DHCP.
The NAT rules basically ignore the DNS lookup address (whatever address anyone on the LAN uses) and sends everything to the pihole. That way I can use DoH and prevent some DNS workarounds.
I can also turn those rules off with a script really easily, if the pihole stops working, and the router will be used as the DNS server.
I have similar configuration and I don’t use nat rules just appropriate firewall rules, forwards from LAN and VLAN lists to containers bridge and forward containers to WAN for containers internet connection. If I want to quickly switch to ROS DNS I need just to update DNS in DHCP settings to ROS IP on subnet because LAN and VLAN already have input access to router (guest VLAN just to port 53).
Depends what one is trying to acccomplish Optio, one size does not fit all.
Typically forward chain rules are to allow traffic to move between interfaces/users, it doesnt route them, just allows or not.
So forward chain rules are important to allow LAN users to access a different subnets PI server for example.
It doesnt route them there, it just allows for the possibility.
Dst-Nat like IP routes tells the router where traffic should go, which is a totally different thing.
Where you are mixing apples and oranges is that we already have a forward chain rule to allow port forwarding ( traffic from WAN to local resources ) add chain=forward action=accept connection-nat-state=dstnat
All this says is allow traffic with dst-nat.
In the dst-nat rules is where we apply the logic of what is permitted.
FROM WHICH INTERFACE
TO WHICH PORT/PROTOCOL
FROM WHICH SOURCE ADDRESS (often not used but should be).
This is standard port fowarding as we know it and it controls what traffic is permitted from WAN to local resources.
However dst-nat rules are also used for other things like directing traffic to specific locations.
Here it is up to the user to ensure they are limiting the exposure of non-local traffic to these rules…
We could add more forward chain rules for sure, but normally the control or matching attributes are entered in the DST nat rules.
Either OR works!
I have different approach and it works that why I share my approach, I have more subnets than this config (LAN, VLAN, containers, and 2 VPNS) on 2 bridges (LAN and containers), routes are created dynamically and I don’t use dst-nat for port forward between them, just for port forward from WAN.
Drop all else at end of input/forward chains is all that is required.
Then one adds any traffic needed.
Simple clean.
Two or more subnets involved in same FW rules, use interface lists.
Groups of users (less than a subnet) with or without whole subnets involved in same FW rules, use address-lists
Easy to optimize!