[BUG] 'Override DNS Settings for All Clients' opens up Port 53 to the WAN

Hey all,

While port scanning my ar750s (3.101) from the WAN side (while connected to the same WiFi network with another client on the same subnet as the ar750s) I noticed that Port 53 is open.

However, when the ‘override DNS’ setting is disabled I noticed that Port 53 is closed to the outside network.

Checking the real-time connection graphs in LuCI I also notice many ICMP connections to dns.google:undefined from the router. I thought this may be from my Chromecast but perhaps this is from mwan3track and unrelated.

I have openVPN client, Killswitch and adblock running.

Is this normal?

I would think that the router’s firewall should definitely block Port 53 to the outside network. It seems that the Override DNS function is not working as expected but perhaps I’m wrong - I would appreciate some clarifications if any one has any.

EDIT: same with 3.104 from testing

This is probably a bug. Port 53 should only be open when hosting DNS zones, which i don’t see why the router would do to the outside internet.

Port 53 is open on DNS servers to handle the DNS queries.

1 Like

Certainly seems that way!

… as far as the constant ping too Google DNS is concerned, I am 99% sure that it’s mwan3 and completely unrelated.

Hopefully, the custom DNS options will be tested by gl.inet staff for leaks when used in conjunction with other functions such as wireguard or openVPN.

I would hate to think that I am exposing a DNS server to my VPN provider or the clients on the outside network… or worse yet - the WAN!!!

Hello chromebook,

I can confirm that this is a BUG.
DNS over all uses the DNAT approach to forward DNS requests. However, in the rules of the WAN port, the connection of the DNAT phase will be allowed to pass through.

Thank you for helping us find the problem and we will fix it as soon as possible.


Thanks for the reply, I’ve updated the title to reflect that it is indeed a bug. I’ll let you Mark the issue as solved whenever you feel is best.

Hi @luochongjun, I’m wondering if there’s an estimate for when a fix for this will be available?

FYI currently running 3.105 on my Brume and this bug still appears to exist.

I just verified and it is true on MV1000. I do not have this on MT1300. Just filed internally.

1 Like