Hi @teleney! Thanks so much for your reply.
Unfortunately, what you've suggested doesn't resolve the issue at hand. It's more of a workaround than a solution. Allow me to explain.
"Allow Custom DNS to Override VPN DNS" (your second screenshot) was never toggled on for me at any point in the lifetime of me owning the routers I have from GL.iNet. So, we can eliminate that from further consideration here.
Yes, toggling off "AdGuard Home Handle Client Requests" in the GL.iNet UI (as shown in your first screenshot) avoids DNS leaks, but that's a workaround rather than a resolution to the problem I've raised. The approach you suggest completely removes key functionality within AdGuard that's enabled when you have that option toggled on. For example, with that option toggled off, I lose both (1) the ability to have client-specific rules configured within AdGuard and (2) client-specific query logging, because toggling off "AdGuard Home Handle Client Requests" results in everything being resolved through "localhost" with a static IP address instead of the actual client IP addresses. (1) and (2) are huge parts of AdGuard's functionality, particularly (1). Moreover, in my view, it is a serious issue that users will experience DNS leaks (perhaps unbeknownst to them) if that option is turned on and they also try to connect devices to a VPN client on the router. In the world of "features and bugs", that's definitely a bug.
To draw an analogy, the problem I've identified above is kind of like me pointing out a problem with my company's cars that are intended for employee use, along with a solution to fix that problem. Your proposed workaround (of toggling off "AdGuard Home Handle Client Requests") is kind of like telling me my employees can still get to their final destinations by taking a bus, train, taxi, etc. Yes, the workaround sort of accomplishes the end goal (i.e., yes, I can still achieve some degree of ad blocking / control over DNS resolution), but it doesn't fix the problem with my company's cars directly (i.e., it doesn't resolve the DNS leak issue I've found). Moreover, using the workaround also results in loss of insight and control along the way to that final destination: I'm now reliant on the singular navigation system of the bus, train, taxi, etc. rather than my the GPS within each of the company cars (i.e., I can only set global rules to be resolved through the "localhost" custom IP that handles all traffic being processed by AdGuard), and I thus also lose the ability customize the route or allow or disallow certain music while driving if desired depending on who's driving the car, where they're trying to go, etc. (inability to have client-specific DNS rules). It also severely limits my ability to monitor things along the way (inability to have client-specific query logging).
However, the solution I present in my original post resolves this. It achieves exactly what you say
while still allowing that fuller functionality of AdGuard Home. I really hope GL.iNet will consider this more fully. I'm happy to partner with you all in talking through things more if you'd like.
Lastly, with respect to your comment
I'd be happy to do this if I had more of a spare router to tinker with, but my routers from you all right now are in such regular use (and need continual reliability and stability in their deployments) that I cannot really play around much with beta firmware on them. However, I did sign up to be a beta tester of the Flint 3, so if I'm selected as a beta tester for Flint 3, I would also then have the opportunity to beta test the 4.8 firmware!
Thanks for everything you and everyone else at GL.iNet does! Your commitment to your customers really shows, and I really appreciate it!
