Flint 2 (GL-MT6000 ) - bug reports - collective thread

I had a hunch and connected my Flint 2 to the internet through mobile tethering. Same results. Just enabled Adguard here and the VPN with Proton with the same custom dns override toggled off.

Maybe I'll replace this router as it might be a hardware thing

In case it is of help, I have custom dns set on - the AdGuard default I believe as I didn't change it. Firmware is 4.6 beta 3 with default settings.

I noticed that you were trying out browserleak for testing, I tried to visit the site and found that the domain used for testing was browserleaks.org instead of browserleaks.com, please try adding browserleaks.org to the policy list, or, You can also test using dnsleaktest.com, which uses the same test domain as the domain you're accessing.

1 Like

Should also be added.

Thanks, my bad I should have spotted that. I reset the router by flashing 4.6.0-op24 & wiping settins. I then enabled Adguard, configured VPN by adding the below domains to the PBR routing config. Override custom DNS is disabled. DNS Leaks still occur when the VPN client is off.


I can see the lookups in Adguard

With Adguard disabled I can see the lookups leaking the ISP DNS

1 Like

This situation should not be leaked, @hansome please test it.

Did you turn off VPN by UI? Could you export me a syslog by PM?

1 Like

Sent you a private message

OpenWrt 21.02-SNAPSHOT r15812+1073-46b6ee7ffc / LuCI openwrt-21.02 branch git-22.335.71649-0ecaf74

4.6.0 beta 2


Initial tests regarding DNS leak (?), or any leak for that matter, does confirm when connecting to VPN via Flint 2 (GL-MT6000) my physical location is revealed.

The same browser on the same session on My IP Address - BrowserLeaks utilizing pfSense firewall, my location is not revealed, with the same VPN provider.

I had Adguard enabled at one point, yet I had disabled Adguard service on the Flint 2.

Where do I check on the router, logs, or so forth to know the cause of this?


It could be I am misreading the charts, that is, the first server I am connecting to of the VPN provider's service is located at the same state I am in, even though the VPN supposedly connecting me to a different state server.

A DNS leak test shows no leak of IP is happening at https://www.dnsleaktest.com

Edit: I think this is the case, connecting pfSense to the same server that is offered (matching Flint2 VPN server), does reveal the state I do live in, at My IP Address - BrowserLeaks . So this could be just an indicator of the first server I am connecting too, rather than being a DNS leak.

Thank you

1 Like

I'm not sure exactly what you're reporting. For the issue I'm having @hansome was able to reproduce it

1 Like

I'm still wondering about updating from 4.5.2 to 4.5.8, is it recommended I do so? and should I toggle off the "keep settings" toggle and start fresh? Thanks.

You should start fresh since 4.5.8 uses different proprietary drivers.


The DNS traffic separation for mt6000-op24 firmware has been fixed. It only impacts the op24 version and domain/ip policy use VPN case. The root cause is our code is not robust enough to adapt to dnsmasq version upgrade.
It will be available in tomorrow's snapshot, and soon a release version.


Thanks for confirming that.

However I'm sure it does affect the normal stable firmware, after all I tried different firmwares to see where the issue was present in them. If it wasn't an issue on the stable firmware I wouldn't have posted here.

I can retest the stable firmware and get back to you on this.

1 Like

I also tried firmware 4.5.8, it works as expected. Firmware 4.6 mostly addresses abnormal cases when custom DNS is used combined with VPN policy.

1 Like

yep, looks like no DNS leak on 4.5.8 when adguard is off, unfortunately when turned on there is some leaks, maybe because this firmware doesn't have the additional setting for custom dns.

However I ran into the bug again where all traffic goes over the VPN when in PBR mode.

I'll try to do some more testing and troubleshooting and report that as a separate issue.

This is what initially made me test the other firmwares where I then found the DNS bug.

Edit: I reproduced an issue whereby all DNS requests seem to go over client VPN on 4.5.8 but I think this is intentional due to the lack of custom DNS setting.

Maybe firmware beta 4.6.0 will be for me now until the new version in snapshot or stable.

1 Like

Hmm could domain resolving also be broken when the endpoint is a domain?

i was troubleshooting my own wireguard server but i came to the conclusion something isn't functioning right on my MT3000 with the OpenWrt 24 snapshot, when i use the client configuration on my phone with wifi off it works correctly, i guess the issue got introduced since the new dns option.

Though the behaviour is very strange when i look on the upstream router where the wireguard server is (which use plain OpenWrt 24), when i replace the portforward from wan with lan where the router firewalls zone resides the MT3000 connects, but the routing doesn't follow wan and its public endpoint ip, but MT3000 does say connected to my endpoint which isn't completely valid.

Atleast its good to know its not my routing of the wgserver or a closed port because my phone was able to connect through the mobile network with the vpn server.

Any idea what might be the cause?, if this bug is not related feel free to move this topic :+1:

It's not like a DNS issue. Can you give more details of your settings?

Ive been testing more it also happen on the mtk version, but i think its normal behaviour, my suspicion is that my old mt6000 firewall config was broken with corrupt nftables rules which allowed this type of behaviour.

so in my case it only works if i add these two portforwards on my mt6000:

the second portforward applies when the mt3000 is connected local on my pcnet zone, on my peer status it shows a localised endpoint which on my previous config was not the case, though it is disabled on my dhcp settings on the mt6000.

this is how it shows on my peer status on my mt6000:

On the mt3000 (the wgclient) i had removed my ddns domain and used the isp ip though it would end up the same:

I see very strange localised nat reflection but i don't know exactly if this is intended by wireguard, if that portforward from pcnet is removed the mt3000 no longer can connect even though it had a wan ip assigned, it wants it to localise the endpoint upstream.

^ pcnets firewall zone only forwards to wgclient (mullvad).

I came to the conclusion its probably normal😋, ive been verfying this on my phone network aswell without wifi and the wan portforward works fine.

1 Like