So why not just host adguard on a rpi instead of your self-promoting-ad-campagne on the forums.
Not to mention that you're just another vibe-coded solution to a problem that doesnt exist and has been solved multiple times already.
Delusions.
this is funny i checked you up and saw you are having the problem i am talking about ...the doh on quad9 .....
the only problem i have with you is just you can't just understand the simple operation flow but i understand some of us have limited understanding we can force all those content in your head
When someone abandons a technical debate to resort to 'you're just too dumb to understand,' it's the universal white flag of a lost argument.
Your 'simple operation flow' gets bypassed by a standard Android phone. Your marketing claims were debunked by your own documentation. And you already admitted you had zero data to back up the hardware claims in your original pitch. Now you're just throwing insults because you have nothing left.
You can absolutely run AdGuard on a Raspberry Pi. That isn't the problem I'm solving. The point is centralised DNS filtering integrated into VPN peer management. An administrator can enable filtering for a router's VPN peer through a policy group, without installing AdGuard on that router or separately managing its filtering service. If a Raspberry Pi meets your needs, use one. If you're managing multiple remote routers, centralised policy control offers a different operational advantage. Running AdGuard on a Raspberry Pi answers where the service can run. It doesn't answer how filtering is managed across a fleet of VPN-connected routers.
Netmaker, tailscale, headscale, firezone...
bro i never asked for examples .....but thanks for nothing
they do everything you do, but better
DoH bypass is not a TunGuard problem; it's a DNS enforcement problem. Put the same Android phone behind a MikroTik running local AdGuard, and its encrypted DNS can bypass filtering there too unless additional controls are enforced. Local AdGuard doesn't magically solve DoH bypass. Centralising AdGuard doesn't create it. It's the same fundamental limitation, regardless of where the resolver runs. The difference is that TunGuard adds centralised filtering through VPN peer policies. You're criticising a universal limitation as if it's a flaw unique to this architecture.
i know about that......and thats not a technical argument but thanks for nothing again
so what exactly is your selling point here? even tho znevna proved you have no concrete benchmarks that would give u foundation for your claims and give us some metrics as to why we would use your product instead of the other ones.
Thanks for wasting everyones time 
We literally just covered this. Standard AdGuard doesn't market itself with the false promise of "DNS filtering without relying on client settings." You did.
Where are those numbers?
And by the way, those are VPN platforms, not evidence that they implement the same AdGuard integration and per-peer DNS-filtering workflow.
If they do it better, name the specific feature, explain how it works, and show how it matches this implementation.
Listing project names isn't a technical comparison.
and you just weasted your time on you own actually ...again thanks for nothing...thats what you contribute @Znevna atleast challenged me
I've acknowledged that my original wording could have been clearer, and I've explained the limitations of port-53 interception. Those limitations are also documented in the original post. The proposal is about centralised DNS filtering and per-peer management, not a claim that encrypted DNS cannot bypass interception. I've also acknowledged that hardware-specific benchmarks would strengthen my resource-consumption claims. I've addressed both criticisms. We can disagree about the design, but repeating acknowledged points isn't adding anything new to the discussion.
Well, seen from here, after having challenged you, he proceeded in crushing the very foundations of your claims.
1st set: Znevna 6 - Tunguard 0
Gentlemen, please change courts. 
Interesting scoreboard. Could you list the six technical points that supposedly invalidated the architecture, rather than simply counting replies? I've acknowledged the wording ambiguity, documented the DoH limitations, and admitted that hardware-specific benchmarks would strengthen the resource claims. A longer argument isn't automatically a stronger argument. Let's score the technical points, not the number of replies. 
-
Resource consumption: Unproven without comparable benchmarks. No architectural invalidation established.
-
Cloud DNS latency: Depends on topology and caching. No universal latency penalty established.
-
Encrypted DNS bypass: A real limitation of port-53 interception alone, but not necessarily of the complete implementation if other controls exist.
-
LAN client identification: A real issue if rules match only the router's tunnel IP while LAN source addresses are preserved. Whether TunGuard handles this elsewhere needs verification.
-
Alternative architectures: Centralised DNS filtering is not unique to TunGuard. That challenges any claim of uniqueness, not the validity of its integration.
-
Privacy and policy transparency: Legitimate trade-offs, not evidence that the architecture fails technically.
Score: zero demonstrated architectural invalidations from these six arguments alone; two concrete implementation questions (encrypted DNS enforcement and LAN-client identification); the rest require measurements or qualify the scope of the claims.
i thought you were bringing your best vpn platform ....and i said thanks for nothing this was @jaclaz work not yours
any vpn platform is better than ur vpn platform lol, at least the known ones we have have some qualitative benchmarks to back their claims up
on that particular implementation i understand you have low understanding so i have clarify