Blocking GoogleDNS & others via Diversion, Firewall-NSF &/or static routing

[Dux]

I'm blocking content on specific clients by setting DNS Director to "Router" & using Diversion filters. Some apps on these devices are hardcoded to use Google DNS. I'm trying to determine if the following is the best way to prevent these devices from using DNS to bypass my router's DNS & content blocking.

1. to prevent DoH bypass, adding a DoH filter to diversion, such as: Hagezi DNS blocklists encrypted-dns-servers-only
I tested this DoH filter & others on MacOS, they stop browser level DoH used by Firefox or Brave, but do not stop native MacOS DoH profiles or apps from bypassing my router's DNS. Is this because https can't be blocked here or some other reason?

2. to prevent DoT & GoogleDNS bypass, using these Firewall-NSF rules:

These seem to work even on preventing DNS bypass by MacOS DoH and DoT profiles and apps.

If the above settings fail, use static routing of 8.8.8.8 & 8.8.4.4 to go scorched earth on GoogleDNS
see: Unlocator how-to-block-google-dns-on-asus-router
see also: Control D tutorials/roku
Static routing definitely works but seems like overkill as it blocks all GoogleDNS system-wide.

This setup seems to work for now but I don't know if it is optimal for blocking content on the clients while avoiding breakage or other issues. If I overlooked something or it can be improved I would greatly appreciate any insights. Thank you.

 

[drinkingbird]

I'm blocking content on specific clients by setting DNS Director to "Router" & using Diversion filters. Some apps on these devices are hardcoded to use Google DNS. I'm trying to determine if the following is the best way to prevent these devices from using DNS to bypass my router's DNS & content blocking.

1. to prevent DoH bypass, adding a DoH filter to diversion, such as: Hagezi DNS blocklists encrypted-dns-servers-only
I tested this DoH filter & others on MacOS, they stop browser level DoH used by Firefox or Brave, but do not stop native MacOS DoH profiles or apps from bypassing my router's DNS. Is this because https can't be blocked here or some other reason?

2. to prevent DoT & GoogleDNS bypass, using these Firewall-NSF rules:
View attachment 52159

These seem to work even on preventing DNS bypass by MacOS DoH and DoT profiles and apps.

If the above settings fail, use static routing of 8.8.8.8 & 8.8.4.4 to go scorched earth on GoogleDNS
see: Unlocator how-to-block-google-dns-on-asus-router
see also: Control D tutorials/roku
Static routing definitely works but seems like overkill as it blocks all GoogleDNS system-wide.

This setup seems to work for now but I don't know if it is optimal for blocking content on the clients while avoiding breakage or other issues. If I overlooked something or it can be improved I would greatly appreciate any insights. Thank you.

For standard DNS, just use DNS Filter/DNS Director and set it to "router" for all clients. Anything going out via port 53 will be intercepted invisibly and redirected to the DNS you have configured on the router's WAN page. It will *look* to the client like the response is coming from google or wherever, but it really is not.

For DOH, set the option on the wan to prevent browser auto DOH which will stop the browsers from doing it. For hardcoded DOH/DOT, blocking in network services filter like you're doing will work, you do not need to set a source IP, just a destination and protocol (DOH/DOT should always be TCP so you don't have to duplicate the rule for UDP, but you can, won't hurt). That is manageable if it is a short list of IPs and you know what they are. Keep in mind the devices that seem to be bypassing it may be setting up a tunnel of some sort and doing DNS within that, which you can never block. If you want to block all DOH then you can use a blacklist with diversion or one of the other addons to try and block all DNS IPs, but obviously it won't be 100%, but all the common ones should be in there. But again, any sort of VPN or tunnel will bypass that, you'd also have to use a blacklist to block known VPN IPs but those change very frequently so that list is going to be hard to keep up to date.

Chrome DOH or other google related devices may even use a different DNS than those two, you may have to watch the device in question in the connection monitor and see if you can catch what it is hitting. Granted it will be on HTTPS so hard to differentiate from other stuff but worth a look.

BTW no need to blur out your internal 192.168 IPs, nobody can do anything with those. Only your public WAN IP really needs to be blurred.

Bear in mind if you have IPv6 enabled you also need to do all that stuff for the IPv6 IPs also, IPv6 is preferred so it will use that first, probably easier to just disable IPv6.

 

[Morris]

Under LAN, click the route tab and create a static route for 8.8.8.8 255.255.255.255 to any host. Use this for any destination you wish to block.

 

[drinkingbird]

Under LAN, click the route tab and create a static route for 8.8.8.8 255.255.255.255 to any host. Use this for any destination you wish to block.

You can't do it to any host, if you point it to something on the internet it will just still go out the internet (it will hit your default route). You'd need to do a loopback on the router or an internal host.

Easier to just block it in network services filter probably, but either way works, as long as you make sure to point it to an IP that exists somewhere other than the WAN port.

 

[Morris]

You can't do it to any host, if you point it to something on the internet it will just still go out the internet (it will hit your default route). You'd need to do a loopback on the router or an internal host.

Easier to just block it in network services filter probably, but either way works, as long as you make sure to point it to an IP that exists somewhere other than the WAN port.

The list of hosts available in the dropdown are all on the LAN :-} Traditionally, I agree that the place to point is loopback.

 

[drinkingbird]

The list of hosts available in the dropdown are all on the LAN :-} Traditionally, I agree that the place to point is loopback.

Just clarifying. Honestly I never even realized you could drop it down and it was pre-filled, the few times I've needed it just typed in an IP.

I've seen funky behavior with static routes before on my AC1900 so don't really trust it. Maybe better on newer ones.

 

[Dux]

For DOH, set the option on the wan to prevent browser auto DOH which will stop the browsers from doing it. For hardcoded DOH/DOT, blocking in network services filter like you're doing will work, you do not need to set a source IP, just a destination and protocol (DOH/DOT should always be TCP so you don't have to duplicate the rule for UDP, but you can, won't hurt). That is manageable if it is a short list of IPs and you know what they are. Keep in mind the devices that seem to be bypassing it may be setting up a tunnel of some sort and doing DNS within that, which you can never block. If you want to block all DOH then you can use a blacklist with diversion or one of the other addons to try and block all DNS IPs, but obviously it won't be 100%, but all the common ones should be in there. But again, any sort of VPN or tunnel will bypass that, you'd also have to use a blacklist to block known VPN IPs but those change very frequently so that list is going to be hard to keep up to date.

Thank you for your suggestions. I made some changes, so hopefully I'll get this right. All port 53 traffic is going through router.

For blocking hardcoded DoT & Google DoH, in Network Services Filter, if I just want this to apply to my Rokus only (each with manually-assigned IPs), and nothing else, should I not use Source IP for each one as follows?

As for other DoH servers, I'm using this DNS server IP blacklist in Diversion: https://github.com/hagezi/dns-blocklists#encrypted-dns-servers-only-

As to static routing, does it block more than NSF? In the past I've used the following settings with the result being that Google DNS was blocked system-wide, WAN & all clients, even when I tried to limit to a specific host/gateway. I don't know if static routing can block VPN/tunneling though.

 

[drinkingbird]

Thank you for your suggestions. I made some changes, so hopefully I'll get this right. All port 53 traffic is going through router.

For blocking hardcoded DoT & Google DoH, in Network Services Filter, if I just want this to apply to my Rokus only (each with manually-assigned IPs), and nothing else, should I not use Source IP for each one as follows?
View attachment 52177

As for other DoH servers, I'm using this DNS server IP blacklist in Diversion: https://github.com/hagezi/dns-blocklists#encrypted-dns-servers-only-

As to static routing, does it block more than NSF? In the past I've used the following settings with the result being that Google DNS was blocked system-wide, WAN & all clients, even when I tried to limit to a specific host/gateway. I don't know if static routing can block VPN/tunneling though.

View attachment 52179

Yes you can use a specific source IP if you only want to block that one device.

The static route should have basically the exact same impact. I've noticed some oddities with static routing on my older router but it has probably been fixed by now. So in theory you could remove your two NSF rules that specify those IPs and just leave the port 853 one. Either way, just test it after to make sure the static route is doing what it should be. Sometimes if a gateway is not reachable (offline) it would then fail back to the default route to the internet, which is why I liked using 127.0.0.1, but I forget which interface you had to specify to get that to work. Maybe test it with a laptop just to confirm it is working, or stick with NSF, especially if you only want to block it for one particular device, as static routes are global for all devices.

The one time routing works vs. NSF is when there is a VPN in play, I believe the routing can happen before the VPN whereas NSF does not. So you could potentially stop DNS queries from going over the VPN too. If you ever use VPN test that out and see. But again that would affect all of your devices.

 

[Dux]

Yes you can use a specific source IP if you only want to block that one device.

The static route should have basically the exact same impact. I've noticed some oddities with static routing on my older router but it has probably been fixed by now. So in theory you could remove your two NSF rules that specify those IPs and just leave the port 853 one. Either way, just test it after to make sure the static route is doing what it should be. Sometimes if a gateway is not reachable (offline) it would then fail back to the default route to the internet, which is why I liked using 127.0.0.1, but I forget which interface you had to specify to get that to work. Maybe test it with a laptop just to confirm it is working, or stick with NSF, especially if you only want to block it for one particular device, as static routes are global for all devices.

The one time routing works vs. NSF is when there is a VPN in play, I believe the routing can happen before the VPN whereas NSF does not. So you could potentially stop DNS queries from going over the VPN too. If you ever use VPN test that out and see. But again that would affect all of your devices.

Thank you again. since as far as i can tell, firewall NSF + Diversion block what I want (and preventing DNS DoH/DoT bypassing of the same) and nothing more I'll stick with that for now. If the devices manage to bypass that I can try static routing again and if that doesn't work I'll use the devices as hockey pucks...

I tested a VPN today on my laptop, the static routing rules as shown above were unable to stop DNS queries from going over the VPN, so maybe static routing can't stop clients from tunneling?

 

[drinkingbird]

Thank you again. since as far as i can tell, firewall NSF + Diversion block what I want (and preventing DNS DoH/DoT bypassing of the same) and nothing more I'll stick with that for now. If the devices manage to bypass that I can try static routing again and if that doesn't work I'll use the devices as hockey pucks...

I tested a VPN today on my laptop, the static routing rules as shown above were unable to stop DNS queries from going over the VPN, so maybe static routing can't stop clients from tunneling?

Neither can stop things within a VPN. That's the whole point of a VPN. You would have to block VPN completely (another blacklist, one that is much harder to keep up to date, since the VPN providers change IPs frequently as they know they are getting blacklisted).

The VPN I was referring to was on the router. If you run it there, I believe a LAN static route can stop a DNS query (or other destination) from hitting the VPN, whereas NSF can't. However in that case you're better off using the VPN config to block things.

 

[Dux]

OK, i haven't gotten into VPN on the router, hopefully won't have to. I'm trying to keep things simple & reliable.

 

[drinkingbird]

OK, i haven't gotten into VPN on the router, hopefully won't have to. I'm trying to keep things simple & reliable.

Yeah in your case where you just want that 1 device blocked from google DNS sounds like you're good. If you wanted to prevent people from using a VPN to bypass your filtering that's a whole other story, but doesn't sound like the case.