Firewall rules not working for one specific DNS

[peiskos]

Thanks to this forum's help a while back, I've got a janky little setup on my router to block DoH providers using the router's DNS filter settings and a firewall-start script. The script looks like this:

#!/bin/sh
touch /tmp/000firewall-start
# Repeat for each DOH provider
iptables -I FORWARD -s x.x.x.x -j DROP
iptables -I FORWARD -d x.x.x.x -j DROP
...
touch /tmp/000firewall-stop

Now it's been working for every DNS on the list, except Cloudflare's DNS: 1.1.1.1 and 1.0.0.1. I can't figure out why.

Any ideas on how to fix this or an alternate method to block Cloudflare's DNS? I've tried the putting the DNS under the LAN/Route tab in settings, but had no luck.

Thanks in advance for any help or suggestions!

 

[peiskos]

@eibgrad - you had a couple of comments on the last thread (copied below); however, I just didn't understand much of what you said. Do you think this issue is related?

FYI. That list of DOH providers doesn't make for a very efficient firewall. For example, it enumerates every IP from 45.90.28.1 thru 45.90.28.254, and 45.90.30.1 thru 45.90.30.254, for NextDNS, when it would be far more efficient to simply specify 45.90.28.0/24 and 45.90.30.0/24, respectively. IOW, convert them to class C networks.

Also, there's no need to be checking all those IPs for each and every packet. Once a NEW connection is established (which means it passed muster), there's no further need to check it. It would be far better to place the list of IPs in their own user-defined chain, then only check the chain on new TCP connections.

Code:
iptables -N block_doh
iptables -A block_doh -d 168.235.81.167 -j REJECT
iptables -A block_doh -d 176.56.236.175 -j REJECT
...
iptables -A block_doh -j RETURN
iptables -I FORWARD -p tcp -m state --state NEW -j block_doh

 

[ColinTaylor]

How are you determining that this isn't working?

Confirm your rules are being applied correctly with iptables -vnL FORWARD

 

[peiskos]

I have a DNS filter to block certain websites. If I set my laptop's DNS to the Cloudflare DNS, I'm able to access those websites. If I set it to any other DNS (e.g., Google's) or just the default, the website blocking works as intended.

 

[ColinTaylor]

Check the rules using the command I posted.

 

[peiskos]

Do you have any suggestions on how I can run the iptables command on my macbook? It doesn't seem like MacOS supports iptables commands.

 

[ColinTaylor]

You have to log into the router using SSH.

 

[egc]

Cloudfare probably has a lot more DNS servers then the usual IP addresses.
Some browser might simply use cloudfare-dns.com and then use a regional IP address for DNS server.
I use IPSET for DoH blocking but even then you cannot be 100% sure

 

[peiskos]

@ColinTaylor
Not sure how to interpret the output. Here are a few screenshots. The first shows the table header, the second a portion of the table and the third has the DNS addresses that are giving me grief (1.1.1.1 and 1.0.0.1).
Screenshot #1

Screenshot #2

Screenshot #3

 

[ColinTaylor]

We can see that your firewall rule is working as it has dropped 160 connection attempts to 1.1.1.1 and there is also a rule for 1.0.0.1.

Your clients must be reaching it some other way (e.g. a VPN) or your testing methodology is flawed.

 

[peiskos]

I'm not using a VPN.

It seems like using a different browser makes a difference. On Chrome, 1.1.1.1 and 1.0.0.1 are not blocked, but all the others are. On Firefox everything is blocked and working as intended. Not sure why Chrome treats Cloudflare's public DNS differently.

 

[Treadler]

I'm not using a VPN.

It seems like using a different browser makes a difference. On Chrome, 1.1.1.1 and 1.0.0.1 are not blocked, but all the others are. On Firefox everything is blocked and working as intended. Not sure why Chrome treats Cloudflare's public DNS differently.

Looks like Chrome might have DoH enabled.
I assume there’ll be a way to turn it off……

 

[ColinTaylor]

Looks like Chrome might have DoH enabled.

That's the entire point of this thread. See the first sentence of post #1.

 

[Treadler]

That's the entire point of this thread. See the first sentence of post #1.

In which case, my comment should be treated with the contempt it deserves.

 

[ColinTaylor]

It seems like using a different browser makes a difference. On Chrome, 1.1.1.1 and 1.0.0.1 are not blocked, but all the others are. On Firefox everything is blocked and working as intended. Not sure why Chrome treats Cloudflare's public DNS differently.

Can you go to dnsleaktest.com on Chrome and Firefox and compare the results?

What OS are you using, Windows, macOS, Linux?

 

[peiskos]

I'm using MacOS.

Dnsleaktest results from when I'm not trying to use 1.1.1.1 and 1.0.0.1.
Chrome

Firefox

Dnsleaktest results from when I do try to use 1.1.1.1 and 1.0.0.1.
Chrome

Firefox

Chrome is using the Cloudflare ISP, while Firefox is not.

If I true to use another DoH provider, e.g., Google's 8.8.8.8 and 8.8.4.4, Chrome is still working as intended. It's only the Cloudflare DNS that's the problem spot, puzzlingly.

 

[ColinTaylor]

Try running the Chrome test again with Chrome in "Incognito mode".

What are you changing when you say that you are "trying to use 1.1.1.1 and 1.0.0.1".

 

[peiskos]

Chrome test in incognito

I'm setting the DNS servers to the cloudflare addresses in the network settings of my laptop. With the DNS filter enabled through the router settings and the firewall-start script, these settings on my macbook should be ignored/blocked (for DoH or not) and the router DNS settings used instead. If I set the DNS server this way to any other DoH provider, e.g., Google's 8.8.8.8 and 8.8.4.4, it still works. It's just cloudflare.

Chrome test in incognito while using 1.1.1.1 and 1.0.0.1

 

[Tech Junky]

It's fairly simple.... disable securedns in chrome.

Chrome is funny in the way it works... I have issues with it bypassing Pihole on the phone and have to close / reopen it to trigger things to work properly. On the phone though there's 2 sDNS functions you have to turn off. one for the OS itself and one for the browser.

I would think blocking the servers at the router level would work but, devices are trying to sell your data any way possible.

It took a bit of effort to get clean results. For me this involves changing the DNS on the VPN client to point internal to the Pihole instead of allowing direct access. By doing this change though I also capture a lot more data on the pihole I wasn't seeing before from local lookups on my DIY box for DNS.

Regardless of what you do though if the client OS is able to make changes to their DNS manually unless you change the policies to lock them down you'll have ways around your restrictions at the network level.

Ultimately you could just block access to 1.1.1.1 / 1.0.0.1 through a iptables entry telling the router to drop all traffic to them.

Alternatively you could use some ipset groups and rules to auto add the servers to the group and drop them automatically. I was doing this for something else and then just said screw it and just locked things down a different way.

 

[ColinTaylor]

Ultimately you could just block access to 1.1.1.1 / 1.0.0.1 through a iptables entry telling the router to drop all traffic to them.

That's exactly what he's doing and the entire point of this thread. See post #1.