OpenWRT block DNS-over-TLS coming from LAN

[Duvet]

I have OpenWRT set up with DNS over HTTPS on the router. This works quite well.

But also have Private DNS on my Android cell phone. This Private DNS is a DNS-over-TLS server. My cell phone can't access Private DNS when connected to the OpenWRT router.

The same cell phone can access Private DNS very easily on other networks, both mobile and wifi.

I also have a laptop with DNS-over-TLS. The laptop also cannot access DNS-over-TLS through the OpenWRT router.

For testing, I disabled the firewall on the router (service firewall stop). I still couldn't get through with DNS-over-TLS. I'm not sure it's the firewall that's blocking the requests.

What else could I try?

[pavelgl]

@Duvet

For testing, I disabled the firewall on the router (service firewall stop).

Stopping the firewall service will also stop masquerading on the wan zone and all lan clients will lose Internet access, so this is not a useful test.

In addition have you also followed DNS hijacking and created a rule like this?

[account4538]

By default port 853 should not be blocked, but as a test write a firewall rule to accept port 853 from LAN to WAN

[Duvet]

Stopping the firewall service will also stop masquerading on the wan zone and all lan clients will lose Internet access, so this is not a useful test.

That's good to know, thanks.

I do DNS hijacking for plain port 53 requests, but I don't have a rule to catch 853 as suggested there.

[porshuram]

from the file /etc/config/https-dns-proxy remove the line
list force_dns_port '853'

and reboot the router

[Duvet]

Awesome, that did it! Out of curiosity, what specifically does that line do?

[porshuram]

hijack dns request over that port and return via https dns

[Duvet]

Thought so. But a request on 853 would be encrypted anyway, so how would the router be able to interpret it?

[porshuram]

it was actually hijacking all traffic on port 853 that is it was preventing all connection forwarding to wan over port 853.
in other word all the connection over that port didn't go to wan directly.

and the https-dns-proxy was designed to listen for clear dns over listed ports. as it was encrypted the proxy just didn't recognize and dropped it. and the private dns didn't get right answer.

*all the above things i've written is my theory