DNS over TCP to router on guest network not working

[dns]

I'm not sure if this is a Merlin specific issue but I would rather not install the official firmware right now. I'm on 388.2_2

DNS over TCP to the router doesn't work on my guest network with "Access Intranet" set to "Disable". It works fine if I use a public dns server. Is there a setting for this somewhere? Or is it a bug? The only workaround I can come up with is installing YazFi but I'd rather avoid installing an add-on.

This becomes a problem when I want to enable DNS Director to force everything through the router which uses a local dns server (Pi-hole) as it's upstream.

examples:

nslookup asus.com 192.168.102.1
Server:         192.168.102.1
Address:        192.168.102.1#53

Non-authoritative answer:
Name:   asus.com
Address: 103.10.4.227

nslookup -vc asus.com 192.168.102.1
;; Connection to 192.168.102.1#53(192.168.102.1) for asus.com failed: timed out.
;; Connection to 192.168.102.1#53(192.168.102.1) for asus.com failed: timed out.
;; connection timed out; no servers could be reached
;; Connection to 192.168.102.1#53(192.168.102.1) for asus.com failed: timed out.

nslookup -vc asus.com 1.1     
Server:         1.1
Address:        1.0.0.1#53

Non-authoritative answer:
Name:   asus.com
Address: 103.10.4.227

192.168.102.1 is the gateway for the guest network. But you could replace it with 192.168.1.1 which is the gateway for the main network. Both respond the same.

Thanks in advance!

 

[ColinTaylor]

It's the way Asus has implemented guest isolation. They block TCP connections to the entire LAN (including the router) but allow UDP. Yep, it's crap.

 

[Justinh]

Colin, does this mean the firewall is not in used for the guest network?

 

[ColinTaylor]

Colin, does this mean the firewall is not in used for the guest network?

Sorry, what firewall are you referring to?

 

[bbunge]

I'm not sure if this is a Merlin specific issue but I would rather not install the official firmware right now. I'm on 388.2_2

DNS over TCP to the router doesn't work on my guest network with "Access Intranet" set to "Disable". It works fine if I use a public dns server. Is there a setting for this somewhere? Or is it a bug? The only workaround I can come up with is installing YazFi but I'd rather avoid installing an add-on.

This becomes a problem when I want to enable DNS Director to force everything through the router which uses a local dns server (Pi-hole) as it's upstream.

examples:

nslookup asus.com 192.168.102.1
Server:         192.168.102.1
Address:        192.168.102.1#53

Non-authoritative answer:
Name:   asus.com
Address: 103.10.4.227

nslookup -vc asus.com 192.168.102.1
;; Connection to 192.168.102.1#53(192.168.102.1) for asus.com failed: timed out.
;; Connection to 192.168.102.1#53(192.168.102.1) for asus.com failed: timed out.
;; connection timed out; no servers could be reached
;; Connection to 192.168.102.1#53(192.168.102.1) for asus.com failed: timed out.

nslookup -vc asus.com 1.1    
Server:         1.1
Address:        1.0.0.1#53

Non-authoritative answer:
Name:   asus.com
Address: 103.10.4.227

192.168.102.1 is the gateway for the guest network. But you could replace it with 192.168.1.1 which is the gateway for the main network. Both respond the same.

Thanks in advance!

DoT does work from a guest WIFI. At least in the Asus factory firmware and it should work in Merlin. I just tested it with my Pi4 connected to my guest WIFI.

However, directing DNS through a Pi-Hole from clients on a guest WIFI is another matter. I'm shure it has been done. But, a simpler approach is to add Diversion to your router. It can use the same block lists as Pi-Hole and will work with your guest WIFI. Save your RPI for something fun!

 

[ColinTaylor]

DoT does work from a guest WIFI. At least in the Asus factory firmware and it should work in Merlin. I just tested it with my Pi4 connected to my guest WIFI.

However, directing DNS through a Pi-Hole from clients on a guest WIFI is another matter. I'm shure it has been done. But, a simpler approach is to add Diversion to your router. It can use the same block lists as Pi-Hole and will work with your guest WIFI. Save your RPI for something fun!

Ah, he actually asked about "DNS over TCP", not DNS over TLS (DoT). If he really meant DoT then my previous answer is not applicable.

EDIT: Looking back at his post he was asking about TCP, because his example uses nslookup -vc.

 

[bbunge]

Ah, he actually asked about "DNS over TCP", not DNS over TLS (DoT). If he really meant DoT then my previous answer is not applicable.

EDIT: Looking back at his post he was asking about TCP, because his example uses nslookup -vc.

I feel he really intended DoT because conventional DNS uses UDP and DoT does use TCP.

Oops.. I just learned that conventional DNS can use TCP when responses are larger than the default (512 bytes?) as in DNSSEC responses. However, the OP likely does not know this and really meant DoT...

 

[dns]

I feel he really intended DoT because conventional DNS uses UDP and DoT does use TCP.

Oops.. I just learned that conventional DNS can use TCP when responses are larger than the default (512 bytes?) as in DNSSEC responses. However, the OP likely does not know this and really meant DoT...

Nah I mean TCP.

 

[dns]

It's the way Asus has implemented guest isolation. They block TCP connections to the entire LAN (including the router) but allow UDP. Yep, it's crap.

Thanks for this. Guess I'll figure out YazFi or get myself a new router.

 

[bbunge]

I ran those same commands:
nslookup asus.com 192.168.101.1
Server: 192.168.101.1
Address: 192.168.101.1#53

Non-authoritative answer:
Name: asus.com
Address: 103.10.4.227

nslookup -vc asus.com 192.168.101.1
Server: 192.168.101.1
Address: 192.168.101.1#53

Non-authoritative answer:
Name: asus.com
Address: 103.10.4.227

nslookup -vc asus.com 1.1
Server: 1.1
Address: 1.0.0.1#53

Non-authoritative answer:
Name: asus.com
Address: 103.10.4.227

Only difference is I used guest 1 on my 2.4 GHz and I used Asus firmware.

So, the question is why did I get an answer to: nslookup -vc asus.com 192.168.101.1

 

[dns]

I ran those same commands:
nslookup asus.com 192.168.101.1
Server: 192.168.101.1
Address: 192.168.101.1#53

Non-authoritative answer:
Name: asus.com
Address: 103.10.4.227

nslookup -vc asus.com 192.168.101.1
Server: 192.168.101.1
Address: 192.168.101.1#53

Non-authoritative answer:
Name: asus.com
Address: 103.10.4.227

nslookup -vc asus.com 1.1
Server: 1.1
Address: 1.0.0.1#53

Non-authoritative answer:
Name: asus.com
Address: 103.10.4.227

Only difference is I used guest 1 on my 2.4 GHz and I used Asus firmware.

So, the question is why did I get an answer to: nslookup -vc asus.com 192.168.101.1

Thanks! And you have Access Intranet set to Disable?

 

[bbunge]

Thanks! And you have Access Intranet set to Disable?

Yes.

Edit: Just for S&G's I set up a guest 1 on 5 GHz and ran the same commands as I ran on the 2.4 GHz band. I got the same results!

 

[ColinTaylor]

Yes.

Edit: Just for S&G's I set up a guest 1 on 5 GHz and ran the same commands as I ran on the 2.4 GHz band. I got the same results!

Maybe Asus fixed it. What do you see from this command?

ebtables -t broute -L

 

[bbunge]

Maybe Asus fixed it. What do you see from this command?

ebtables -t broute -L

ebtables v1.8.7 (nf_tables): table 'broute' is incompatible, use 'nft'tool.

 

[dave14305]

ebtables v1.8.7 (nf_tables): table 'broute' is incompatible, use 'nft'tool.

Run it on the router.

 

[bbunge]

Bridge table: broute

Bridge chain: BROUTING, entries: 16, policy: ACCEPT
-p IPv4 -i wl0.1 --ip-dst 192.168.101.1 --ip-proto icmp -j ACCEPT
-p IPv4 -i wl0.1 --ip-dst 192.168.101.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl0.1 --ip-dst 192.168.50.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl0.1 --ip-dst 192.168.101.0/24 --ip-proto tcp --ip-dport 53 -j ACCEPT
-p IPv4 -i wl0.1 --ip-dst 192.168.50.0/24 --ip-proto tcp --ip-dport 53 -j ACCEPT
-p IPv4 -i wl0.1 --ip-dst 192.168.101.0/24 --ip-proto tcp -j DROP
-p IPv4 -i wl0.1 --ip-dst 192.168.50.0/24 --ip-proto tcp -j DROP
-p IPv4 -i wl0.1 --ip-dst 192.168.101.0/24 -j SKIPLOG
-p IPv4 -i wl1.1 --ip-dst 192.168.102.1 --ip-proto icmp -j ACCEPT
-p IPv4 -i wl1.1 --ip-dst 192.168.102.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl1.1 --ip-dst 192.168.50.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl1.1 --ip-dst 192.168.102.0/24 --ip-proto tcp --ip-dport 53 -j ACCEPT
-p IPv4 -i wl1.1 --ip-dst 192.168.50.0/24 --ip-proto tcp --ip-dport 53 -j ACCEPT
-p IPv4 -i wl1.1 --ip-dst 192.168.102.0/24 --ip-proto tcp -j DROP
-p IPv4 -i wl1.1 --ip-dst 192.168.50.0/24 --ip-proto tcp -j DROP
-p IPv4 -i wl1.1 --ip-dst 192.168.102.0/24 -j SKIPLOG

 

[ColinTaylor]

Ah, so it is different now. They've added an exception for DNS over TCP. But looking at Merlin's code that might only be present when DoT is enabled in the WAN settings. That appears to have been picked up by Merlin with the GPL merge for 386.6.

@bbunge Are you using DoT on your stock firmware?

 

[bbunge]

Ah, so it is different now. They've added an exception for DNS over TCP. But looking at Merlin's code that might only be present when DoT is enabled in the WAN settings. That appears to have been picked up by Merlin with the GPL merge for 386.6.

@bbunge Are you using DoT on your stock firmware?

Yes

 

[dave14305]

Still trying to understand what DoT has to do with 53/tcp…

 

[ColinTaylor]

Still trying to understand what DoT has to do with 53/tcp…

Good point.