Hi there, I have been using GL.iNet products (Flint, 2x Flint 2, Slate AX, and Slate 7) for the past 4-5 years but am new to the forum here.
I am using the 4.8.1 2025-08-14 daily snapshot firmware to allow me to run multiple (5) Surfshark Wireguard VPN tunnels on my Flint 2 at home. The policy-based VPN split tunneling is working great and I am able to use several streaming services from Canada, the UK, Australia and the United States by specifying which domains to access through each VPN tunnel.
For content filtering and ad blocking, I am using NextDNS as a DNS resolver. I am doing this by running AdGuard Home (with no filters) and sending DNS queries to NextDNS over QUIC (DoQ). The DNS resolution and ad blocking through NextDNS is also working well.
However, when I put dns.nextdns.io as a domain to include or exclude from a particular VPN tunnel, DNS queries to the upstream server at quic://[UniqueId].dns.nextdns.io are not following this VPN policy or being sent through the WAN instance/non-VPN tunnel. Instead, all DNS queries are being sent through one of the VPN tunnels - most often (but not always) through the VPN tunnel with the highest priority or sometimes, when a particular VPN tunnel goes down and back up, then through that tunnel. I have the 'Allow Custom DNS to Override VPN DNS' setting enabled under Network > DNS.
As a result, this is impacting the DNS resolution times and latency. Is this behavior a bug? If not, is there a way for all queries to the upstream DNS server to follow the specified domain-based VPN policies or default to the WAN instance/non-VPN tunnel?
Any suggestion or fix would be greatly appreciated. Thank you!
Thank you for the suggestion but it does not. I have tried DOH, DOT and DOQ through AdGuard Home and all of them have the same behavior.
I just tried opening Now TV, which runs perfectly through the UK VPN tunnel, but the DNS queries are being directed through the Canada VPN tunnel, which has higher priority than the UK VPN tunnel.
If I open test.nextdns.io in a web browser, the domain-based VPN tunneling works as expected - the srcIP points to the WAN IP. However, the client and destIP show that the DNS queries are being sent through the wrong tunnel.
So I know I need another dose of caffeine in me but until then: it's the expectation any traffic to nextdns.io — which is not on any policy list — should hit the WAN like any other traffic rather than (tunnel) Priority 1 - CA VPN or a fail-over tunnel, correct?
If so I'm really starting to lean on the side you may have discovered a bug but I'm going to step back & wait for what GL support has to say. It's very curious.
Bumping this up as the erratic behavior of indeterministic DNS query routing continues. The DNS queries are initially routed through the VPN tunnel with the highest priority but, if a VPN tunnel goes down, the DNS queries start getting routed through that erratic VPN tunnel causing high DNS resolution times.
