Fair criticism. The resource impact depends on the hardware and workload; I should have been more specific. But let's not confuse an unsupported performance generalisation with an invalid architecture. You can challenge my numbers without disproving my design. If you have a technical objection to centralised, per-peer DNS filtering, make it. Otherwise, we're arguing about an unquantified performance claim, not the architecture itself.
Nice benchmarks. But a Raspberry Pi 4 with 8 GB RAM demonstrates what Technitium can do on that hardware, not what every MikroTik router can run. My proposal targets centralised, per-peer filtering through existing VPN management. If your hardware supports local filtering and that suits your deployment, great. The question isn't whether local DNS filtering works. It's whether every edge router should have to run it.
kindly re-read the post we are not comparing pi here.......you are outside the topic of discussion....thanks for nothing though
Those figures stand on a Cap ax Hap ax^2 which is what I have and use. Your topic. "Stop Using Adguard" So What are the figures, I am sure I am not the first person to ask. So convince me why I would use it, what do i have to gain in terms of speed security over what Mikrotik already offer with containers etc. No need to rude bud.
This looks like a practical solution for routers with limited RAM and CPU. I’d also recommend restricting DNS access to trusted VPN peers and securing the VPS firewall to prevent abuse. How do you handle DNS-over-HTTPS clients that bypass standard port 53 filtering? 
I think you're evaluating this from the perspective of a single router, while the proposal addresses the VPN infrastructure as a whole. If your MikroTik runs AdGuard reliably in a container, keep using it. I'm not claiming my approach will make your DNS queries faster. The point is to integrate filtering into the existing VPN management layer: centralised filtering, per-peer control, and no requirement to deploy AdGuard on every edge device. You're asking what advantage this gives one capable router. I'm addressing what it takes to manage DNS filtering across an entire fleet, including devices that can't run AdGuard at all. Those are different deployment requirements, and that's precisely why alternative architectures exist.
TunGuard already supports this. The documentation explains both VPN-based DNS interception and public DoH/DoT endpoints, including their respective limitations. Filtering is integrated into VPN policy groups, so operators can enable or disable it per peer without regenerating WireGuard configurations. Clients that explicitly use encrypted DNS can also connect to the public DoH/DoT endpoints. Transparent interception and encrypted DNS support are two different things. TunGuard addresses both; they simply work differently. The implementation, configuration, and limitations are documented here: AdGuard DNS Filtering - TunGuard I'd suggest reading the documentation before treating an already-supported feature as a missing capability.
We did read it. Here is what your documentation actually says about handling DoH/DoT bypass:
"Android's Private DNS setting (DNS-over-HTTPS / DNS-over-TLS) encrypts queries and does not use port 53. Port-53 interception cannot see those queries.
To filter an Android device, set Private DNS to Off (or Automatic) in its network settings so its queries actually go to the DNS server the VPN profile configures."
So your "already-supported feature" for handling encrypted DNS bypass is... telling the network admin to walk over to every single client device and manually turn it off?
In your very first post, you pitched this entire architecture on the premise of:
-
"DNS filtering without relying on client settings"
-
"No need to reconfigure every client"
Ethan asked how your setup handles clients that bypass Port 53. You condescendingly told him to read the documentation, and your documentation literally admits it cannot handle it at all without completely contradicting your "no client configuration" sales pitch.
The moment a modern Android phone, iOS device, or DoH-enabled browser joins the network, your transparent interception model is completely blind unless you manually touch the device's network settings.
Pay attention to your own documentation before lecturing people.
You're presenting DoH bypass as if it's a flaw unique to TunGuard. It isn't.
Put AdGuard on your MikroTik, connect a phone using DoH, and the same limitation applies unless you enforce additional restrictions on encrypted DNS. Running AdGuard locally doesn't magically make encrypted DNS visible, just as running it centrally doesn't.
The difference with TunGuard is that filtering is integrated into VPN peer management, allowing operators to control filtering centrally without installing AdGuard on every router.
Deployment and encrypted-DNS enforcement are separate concerns. I've explained that distinction multiple times now.
Kindly take the time to understand the architecture before replying. I'm happy to discuss legitimate technical criticisms, but repeatedly explaining the same basic networking principles because you're conflating deployment with enforcement is wasting everyone's time.
The difference is that a standard local AdGuard deployment doesn't market itself with the promise: "DNS filtering without relying on client settings" and "No need to reconfigure every client." You did.
You built your entire sales pitch on a seamless, transparent interception model. Now that you've been called out on the fact that modern traffic bypasses it, your defense is "well, it's broken for everyone else too."
About those numbers from those budget routers, where are they?
This is the nth time you've deflected from providing a single benchmark for the hardware performance claims that started this entire thread.
Kindly take the time to understand your own contradictions before lecturing others.
You're misunderstanding what I meant by zero configuration. I'm talking about the router. The administrator connects it to the TunGuard VPN, and DNS filtering can be enabled centrally through the peer's policy group. No AdGuard installation, container configuration, or individual DNS setup on the router is required. TunGuard also supports public DoH/DoT endpoints for clients configured to use encrypted DNS. I've documented the limitations of transparent port-53 interception, so I'm not claiming it intercepts arbitrary DoH traffic. Zero-configuration deployment on the router doesn't mean universal interception of every DNS protocol on every device behind it. Those are two entirely different claims.
"1. DNS filtering without relying on client settings" is literally the first bullet point in your OP.
You didn't say "router settings." You explicitly talked about the client devices: "Normally, you'd configure a device to use a particular DNS server and hope it follows that configuration... This catches standard DNS queries over UDP and TCP, even when the client has configured a different DNS server."
You were absolutely talking about the client. Now that you realize modern DoH/DoT bypasses your transparent interception, you're trying to convince everyone you were only talking about the router.
You can stop moving the goalposts now.
(Still waiting on those CPU and RAM numbers, by the way).
This is getting good good 
ChatGPT said:
-
FYI, you haven't used TunGuard, and you're arguing about an implementation you haven't tested. You've acknowledged no actual measurements of your own, and much of this discussion has revolved around theoretical assumptions rather than the implementation itself.
I've explained the architecture, its limitations, and the distinction between deployment and DNS enforcement multiple times. The documentation is public.
If you have a concrete technical objection based on the actual implementation, make it. Otherwise, please stop repeating the same arguments and wasting everyone's time.
I don't know why you're quoting ChatGPT to me, but I don't need to install a VPN script to know that DoH bypasses Port 53. I don't need to benchmark your code to read the first bullet point of your own post where you promised "filtering without relying on client settings."
And I certainly don't need to test your implementation to notice this is the fourth time you've dodged providing the CPU/RAM metrics that your entire pitch was built on.
You invented a hardware crisis on budget routers to spam a solution, got called out on the basic network fundamentals, and now you're just stalling because you don't have the numbers.
My concrete technical objection is that your fundamental premise is marketing fluff. I'll leave you to your sales pitch now.
I'm developing and maintaining a working implementation, not spending my development time manufacturing benchmarks to win a forum argument. The underlying trade-off is straightforward: running another service consumes resources, and the impact depends on the hardware and workload. Centralising AdGuard avoids running that service on every edge router and enables per-peer management through the existing VPN infrastructure. If hardware-specific performance figures become relevant to my users, I'll measure them properly. I'm not going to invent numbers just to satisfy an endless debate. The implementation and its limitations are documented here: AdGuard DNS Filtering - TunGuard The code is there for people who want to evaluate the solution. I'm going back to developing it.
You don't need to invent numbers today because you already invented the CPU and RAM problem in your first post. Thanks for finally admitting you never had any data to back up your sales pitch. Good luck with the development.