I’ve got a brand new MT2500, running 4.1.1 release 2 firmware. I’ve set it up with an OpenVPN connection through NordVPN for two domains - all other traffic is non-VPN. I’m connected to the world through a Comcast cable modem.
Everything works fine most of the time, then occasionally connectivity fails for some non-VPN connections. For example, I suddenly cannot reach Amazon for awhile. Last night, my Echo Dot stopped playing its nighttime noise in the middle of the night, and would not restart because it could not connect to Amazon.
Now the tunnelled domains have absolutely nothing to do with Amazon and have no reason to be implicated in that traffic. The two things that appear to fix the problem are:
Disabling the VPN, or
Switching to global proxy
When that works (it usually does), the problem reappears if I go back to Domain/IP proxy.
I have not figured whether it’s a DNS failure, connection failure, or something else… will explore further. But if anyone recognizes the problem and knows of possible solutions, please speak up. Thanks!
There is no final list of BUG fixes yet, some new features and optimizations are here. For the VPN disconnection case, we do some processing.
# V4.2.0 - Dec 29,2022
## New feature
* Added Parental Control feature.
* Added Zerotier feature.
* Added Tailscale feature.
* Added support for FTP and NFS protocol in network storage.
* Added Clear Traffic Statistics button for in client page.
* Added DHCP Gateway option for LAN.
* Added SSID Visibility option for guest Wi-Fi.
* Added support for GoodCloud alerts when new clients join
* Added support for comments for domain and IP profiles in VPN policy.
## Optimization
* Improved IPv6 LAN Mode options. Separates the native and passthrough modes.
* Improved the results and hints of the DDNS test.
* Improved drop-in gateway feature with DHCP-based solution to increase stability.
* Improved LED lighting logic to ensure consistency with the UI.
* Improved interaction for MAC address cloning.
* Improved networking status alerts in Internet page.
* Improved interface tracking settings description for Multi-WAN.
* Improved login page with automatic focus to password input box.
* Improved VPN client configuration file view with files sorted by name.
* Improved the switch name in the VPN global options for whether the GL.iNet service uses VPN or not.
* Improved the interaction of set read-only users to read-write users in network storage.
* Improved ADGuard Home feature to support seeing which client the request is coming from.
## Language
* Added German language.
Thanks for the recommendation. No joy with the 4.2.0 beta, I’m afraid.
I tried a different configuration: using the “client device” policy for an OpenVPN tunnel, with just a single client device identified by MAC address. When I turned on the VPN, my connectivity to Amazon (from all hosts) fell apart.
So here’s some odd data that might be of interest. First, a ping of www.amazon.com when the VPN is off and all is well:
nmeyers@turing8:~$ ping www.amazon.com
PING d3ag4hukkh62yn.cloudfront.net (52.85.202.189) 56(84) bytes of data.
64 bytes from server-52-85-202-189.lax50.r.cloudfront.net (52.85.202.189): icmp_seq=1 ttl=233 time=14.7 ms
64 bytes from server-52-85-202-189.lax50.r.cloudfront.net (52.85.202.189): icmp_seq=2 ttl=233 time=14.2 ms
64 bytes from server-52-85-202-189.lax50.r.cloudfront.net (52.85.202.189): icmp_seq=3 ttl=233 time=14.4 ms
64 bytes from server-52-85-202-189.lax50.r.cloudfront.net (52.85.202.189): icmp_seq=4 ttl=233 time=14.6 ms
64 bytes from server-52-85-202-189.lax50.r.cloudfront.net (52.85.202.189): icmp_seq=5 ttl=233 time=14.7 ms
64 bytes from server-52-85-202-189.lax50.r.cloudfront.net (52.85.202.189): icmp_seq=6 ttl=233 time=14.5 ms
64 bytes from server-52-85-202-189.lax50.r.cloudfront.net (52.85.202.189): icmp_seq=7 ttl=233 time=14.9 ms
64 bytes from server-52-85-202-189.lax50.r.cloudfront.net (52.85.202.189): icmp_seq=8 ttl=233 time=14.1 ms
64 bytes from server-52-85-202-189.lax50.r.cloudfront.net (52.85.202.189): icmp_seq=9 ttl=233 time=14.7 ms
64 bytes from server-52-85-202-189.lax50.r.cloudfront.net (52.85.202.189): icmp_seq=10 ttl=233 time=14.4 ms
64 bytes from server-52-85-202-189.lax50.r.cloudfront.net (52.85.202.189): icmp_seq=11 ttl=233 time=15.1 ms
64 bytes from server-52-85-202-189.lax50.r.cloudfront.net (52.85.202.189): icmp_seq=12 ttl=233 time=14.4 ms
Now turn on the VPN, wait for things to start failing, and here’s a ping from that same host (again, one not being tunnelled) to www.amazon.com:
nmeyers@turing8:~$ ping www.amazon.com
PING www.amazon.com (198.18.2.14) 56(84) bytes of data.
From lag-1.sdnyoh1703h.netops.charter.com (65.29.36.85) icmp_seq=3 Packet filtered
From lag-1.sdnyoh1703h.netops.charter.com (65.29.36.85) icmp_seq=6 Packet filtered
From lag-1.sdnyoh1703h.netops.charter.com (65.29.36.85) icmp_seq=15 Packet filtered
From lag-1.sdnyoh1703h.netops.charter.com (65.29.36.85) icmp_seq=21 Packet filtered
From lag-1.sdnyoh1703h.netops.charter.com (65.29.36.85) icmp_seq=24 Packet filtered
From lag-1.sdnyoh1703h.netops.charter.com (65.29.36.85) icmp_seq=27 Packet filtered
From lag-1.sdnyoh1703h.netops.charter.com (65.29.36.85) icmp_seq=30 Packet filtered
From lag-1.sdnyoh1703h.netops.charter.com (65.29.36.85) icmp_seq=37 Packet filtered
From lag-1.sdnyoh1703h.netops.charter.com (65.29.36.85) icmp_seq=44 Packet filtered
From lag-1.sdnyoh1703h.netops.charter.com (65.29.36.85) icmp_seq=49 Packet filtered
From lag-1.sdnyoh1703h.netops.charter.com (65.29.36.85) icmp_seq=52 Packet filtered
From lag-1.sdnyoh1703h.netops.charter.com (65.29.36.85) icmp_seq=66 Packet filtered
From lag-1.sdnyoh1703h.netops.charter.com (65.29.36.85) icmp_seq=78 Packet filtered
From lag-1.sdnyoh1703h.netops.charter.com (65.29.36.85) icmp_seq=79 Packet filtered
From lag-1.sdnyoh1703h.netops.charter.com (65.29.36.85) icmp_seq=81 Packet filtered
From lag-1.sdnyoh1703h.netops.charter.com (65.29.36.85) icmp_seq=84 Packet filtered
From lag-1.sdnyoh1703h.netops.charter.com (65.29.36.85) icmp_seq=93 Packet filtered
That destination IP can’t possibly be right!
I’m not using AdGuard Home or any other filters, so we should be able to rule those out.
I see what’s happening here, and I suspect it’s a DNS issue with the MT2500.
I’m in San Diego, but running OpenVPN for some of my client systems to a NordVPN endpoint in Buffalo, NY. When you look up www.amazon.com in Buffalo, it resolves to 198.18.2.14 (or it did at the time I ran this test). When you look it up in San Diego, it resolves to 52.85.202.189 (or it did at the time I ran this test).
I can verify right now that pinging 198.18.2.14 works well on a host tunneled to Buffalo, but not from an untunneled host in San Diego. Amazon doesn’t want clients in San Diego hitting their servers in Buffalo, and my packets are getting filtered out.
Why the problem? My best guess is that the untunneled clients are getting wrong DNS results from MT2500 - getting the results meant for the tunneled clients.
This is not terribly easy to reproduce - it doesn’t happen all the time. But I’m now convinced that, sometimes when MT2500 is running a non-global VPN, it is delivering the wrong DNS results to clients not being tunneled.
More interesting issues. After trying (and failing) to reproduce the amazon.com problem today, I turned off the VPN - so everything’s back to regular router traffic and all is working well… except the router is no longer resolving names for my local network (.lan) - either from dnsmasq or the router’s /etc/hosts. I restored functionality by rebooting the router.
All told, the MT2500’s VPN and DNS are not playing well together.
@luochongjun , any response? This bad DNS behavior is preventing me from using all the capabilities of the product. Both proxied and unproxied hosts should get appropriate DNS responses, and local network lookups should always work.
Doing better with encrypted DNS from Cloudflare turned on! After 12 hours with selective proxying turned on, proxied and unproxied hosts are reaching appropriate DNS servers, and local lookups are still working. So it appears the problems happen when using DNS hosts assigned by DHCP.