Hi all,
I’m running firmware v4.8.1-beta4 on the GL-BE9300 (Flint 3). The build was installed specifically to address the WAN 2.5 G negotiation issue with Virgin Media Routers.
Since enabling AdGuard Home (stock, no tweaks), I’ve been consistently seeing google.com and google.co.uk resolve to 92.249.39.153 instead of valid Google IPs. This happens only when the router’s option “AdGuard Home handle client requests” is disabled (the default).
Symptoms
Browsers can’t reach Google (timeout) - After a period of time. Initially, we can, which is odd
dig @127.0.0.1 google.com +short on the router → 92.249.39.153
Same from LAN clients (nslookup ``google.com`` 192.168.0.1) → 92.249.39.153
Reverse lookup of 92.249.39.153 → NXDOMAIN (no PTR record).
Notes
AdGuard Home’s own config and filters are clean — no rule references that IP.
Behaviour persists even after clearing caches and rebuilding AdGuard Home data.
It looks like the router’s internal dnsmasq/policy engine layer is injecting a “sinkhole” IP for certain Google domains when AGH isn’t the direct resolver.
Is known behaviour or an unintended side-effect of the security/parental-control DNS rewrite logic in 4.8.1-beta4?
If needed, I can provide full diagnostic logs and before/after captures from /root/diag/ showing the issue clearly.
Have you checked the configuration of the Host file and the dnsmasq settings (under Luci → Network → DHCP and DNS) to confirm that no manual mappings were accidentally added?
If possible, please connect the router to GoodCloud and share it with us.
This will allow us to quickly verify whether the issue is due to a configuration error or potentially abnormal behavior from the upstream DNS provider. Technical Support via GoodCloud - GL.iNet Router Docs 4
(After sharing, please PM us the MAC address and the WebUI login password)
Update:
Its really odd; this seems to occur after a period of time. I need to reset the router occasionally to fix it (to access google.?? from Chrome), but cant really tell you how long it takes to error out.
I’ve checked LuCI as requested — attaching screenshots of the Hostnames and DHCP & DNS configuration pages.
Hostnames: only standard entries for console.gl-inet.com (IPv4 + IPv6).
“Resolve specified FQDNs to an IP” is using the default /# → NXDOMAIN rule.
Everything looks standard; there’s no sign of local overrides or configuration errors.
However, the intermittent rewrite of google.com → 92.249.39.153 still recurs after reboot and cache clear.
Environment summary
Device: GL-BE9300 (Flint 3)
Firmware: v4.8.1-beta4 (build for primary WAN 2.5 G negotiation fix)
AdGuard Home: enabled, but “Handle Client Requests” = disabled (default)
VPN: domain-based policies active
Disabling Security, Safe Search, and Block Page options in Network → DNS removes the 92.249.39.153 rewrite.
When AdGuard Home handles client requests directly, Google resolves normally but VPN policies stop working.
May we know are you using Surfshark VPN?
After checking this IP's information, it appears to be an address associated with Surfshark VPN and may be related to its activities.
Thanks — happy to share diagnostics. I’ve redacted sensitive keys/passwords.
Expected behaviour
With “Services from GL.iNet use VPN” = False, all router-local services (AdGuard, GoodCloud, NTP, etc.) should route via the WAN and use the WAN DNS servers (e.g. Virgin Media or manually configured resolvers).
They should not be subject to the VPN routing table or its DNS settings.
Environment:
Yes, I have configured Surfshark VPN for use, but, through Policies, ONLY two clients on my network use this and are configured to use the VPN (Qbittorrent, Jackett).
AdGuard Home: enabled on router, no custom upstreams
Important settings:
“Services from GL.iNet use VPN”: False
“Allow Custom DNS to Override VPN DNS”: Not enabled
ip rule and ip route outputs indicate router-local traffic is being routed via VPN table (rule iif lo lookup 1001)
Chrome (chrome://net-internals/#dns) resolved google.co.uk → 92.249.39.153 (Surfshark/CDN) and Chrome cannot access Google while the router returns that address.
I have redacted private keys and admin credentials. If you need the full logs / config files I can upload them via PM or GoodCloud as requested (I can share MAC and temporary WebUI credentials privately).
Temporary workaround:
I added manual forwarding rules in Luci → Network → DHCP and DNS → Forwards:
127.0.0.1#3053
1.1.1.1
8.8.8.8
and restarted dnsmasq. After this, AdGuard Home began resolving correctly (142.250.x.x) and has remained stable since.
Observation:
The rule “from all iif lo lookup 1001” appears to leak router-local DNS requests into the VPN routing table. Expected:
Router-local services (AdGuard, dnsmasq) should always use the main routing table unless “Services from GL.iNet use VPN” is explicitly enabled.
When “Allow Custom DNS to Override VPN DNS” and “AdGuard Home Handle Client Requests” is disabled,
the router will set the VPN-provided DNS servers as the upstream DNS server of dnsmasq which also provides DNS service to LAN clients.
That’s also why the command
dig @127.0.0.1 google.com +short
returns a VPN DNS resolution result — because 127.0.0.1 corresponds to dnsmasq, which in this case uses the VPN’s DNS servers.
If you want LAN clients to use ADG Home instead of those provided by the VPN, simply enable “Allow Custom DNS to Override VPN DNS” or "AdGuard Home Handle Client Requests".
