then bring it ........on that particular implementation ....in the mean time ........let me take a water break
Is it just me, or does it seem to be consistent with AdverSpamming that the more craptastic the product, the more windy and gaseous the spam gets, with almost zero useful information?
Our own "Billy Mays" of the VPN world . . . . 
i gave you four already
bring the comparison you joined the thread now .....you got it
| Capability | TunGuard | Netmaker | NetBird | Firezone | Headscale |
|---|---|---|---|---|---|
| VPN peer management | Yes | Yes | Yes | Yes, different model | Yes, different model |
| Userspace WireGuard engine | Documented | verified | verified | verified | equivalent established |
| Web dashboard | Yes | Yes | Yes | Yes | Third-party UI options |
| Configuration generation | Yes | Supported, different workflow | Supported, different workflow | Different client model | Tailscale-compatible clients |
| Automated MikroTik provisioning | Documented | verified | verified | verified | verified |
| Optional SSH gateway | Documented | Not verified | verified | verified | verified |
| Central DNS management | Integrated workflow | Yes | Yes | DNS configuration | DNS configuration |
| AdGuard filtering controlled by VPN policy groups | feature | verified | verified | verified | verified |
This is a feature checklist, not a benchmark. More importantly, supporting central DNS configuration isn't necessarily equivalent to integrating AdGuard filtering directly into VPN peer policy groups. If you've verified that all five platforms implement that specific workflow, please link to the relevant documentation for each one. I'd be happy to compare the actual implementations. The question isn't whether other VPN platforms exist. It's whether they provide the same workflow and how their implementations differ.
OMG, please...
Your soft, provide benchmarks too prove that you are right.
Stating that it works fast is nothing without numbers. You should want to prove customers that it is better.
I say that my solutions is the fastest. Prove that it is not.
Since you are begging for more technical points for the scoreboard, let's talk about High Availability.
What happens when the cheap cloud VPS hosting your "architecture" goes offline? (e.g., routing issues, provider outages, or the whole data center goes to literal clouds as we've seen recently).
By forcing all DNS for an entire fleet of routers through a single VPS tunnel, you have engineered a massive Single Point of Failure (SPOF). If that VPS drops, the VPN tunnel drops, the DNS redirects go into a black hole, and every single edge router in your fleet completely loses DNS resolution. The internet goes dark for everyone.
If a local DNS instance fails on a budget router, one location goes down. If your central TunGuard VPS fails, your entire fleet goes down.
How does your "architecture" handle failover for the fleet when the cloud goes poof?
Enjoy your water break. You're going to need it to explain how engineering a single point of failure for an entire ISP/fleet is good network design.
Does your?
Did I advertise some "architecture" in here that I missed? What exactly is the point of that comment?
I'm not the one trying to sell a VPS script to ISPs. But yes, I am at least a tad above average stupid, which means I know better than to shoot myself in the foot by engineering a massive Single Point of Failure for an entire fleet of routers like this topic is advertising.
The burden of proof is on the guy making the sales pitch.
TunGuard is self-hosted infrastructure, not a claim that one VPS is immune to failure. Operators control where they deploy it and can design redundancy around their requirements. If a server fails, TunGuard supports migrating to another server by backing up and restoring its persistent state, including the server's private key, peers, credentials, and configuration. If the replacement retains the same endpoint, existing peers don't need their configurations changed. Centralised management doesn't inherently require a single point of failure; that depends on the deployment architecture. Migration and recovery are documented here: Migrate - TunGuard A single-server deployment is a choice, not an architectural requirement. Recovery is documented; automated high availability is a separate concern.
You are confusing Disaster Recovery (DR) with High Availability (HA).
DNS is the most critical, time-sensitive service on a network. If it drops, the internet appears completely broken to the end user instantly.
Your "architecture" for a fleet failure is literally: let the entire network go dark while the admin manually spins up a new VPS, downloads backups (from an offline VPS, good luck), restore etc.
That is a catastrophic outage, not a fleet architecture.
Claiming you built a centralized DNS solution for ISPs, but dismissing HA as a "separate concern" that operators just need to "design around" themselves is hilarious.
You basically built a single-node script and left the actual hard part of network engineering as an exercise for the reader.
You removed the natural resilience of edge routing, funneled everything into a cloud SPOF, and your answer to a crash is manual server restoration while your users are offline.
The scoreboard is not looking good for you.
Should have some quotes from OP. Missed to include them but you pointed them out:
Claiming you built a centralized DNS solution for ISPs, but dismissing HA as a "separate concern" that operators just need to "design around" themselves is hilarious.
My original post proposed centralised DNS filtering integrated with VPN peer management. It didn't claim to provide automatic HA or uninterrupted service during a VPS outage. You've identified a legitimate consideration for production deployments, but you're treating an optional architectural requirement as though it invalidates the feature being proposed. A documented limitation isn't a broken promise. Critique what I actually claimed, not what you've decided the project should provide.
Yeah ... if server is down how do you want to migrate something from it? What if disk died and the recovery would take hours?
I am critiquing exactly what you claimed. In your original post, you explicitly pitched this centralized setup for "small ISPs" and "networks with remote clients."
High Availability for an ISP's DNS resolver is not an "optional architectural requirement." It is the absolute bare minimum baseline to run a network. If a "small ISP" routes all their customers' DNS through a single cloud VPS, and their official disaster recovery plan is to manually restore an offline backup while the entire customer base loses internet access, that ISP will be out of business by Tuesday.
You didn't build an architecture for ISPs. You built a hobby script for a home lab.
And there's absolutely nothing wrong with building a hobby script! The problem is you brought it to a networking forum, made up fake CPU/RAM crises to sell it, and called it a fleet-ready "architecture"—all while completely ignoring encrypted DNS bypass, data sovereignty, latency physics, and basic network redundancy.
That is what invalidates it
That's precisely why backups should be stored off-server, not only on the VPS itself. If the disk dies, you restore from an external backup; you don't retrieve data from a dead machine. And to be clear, migration is disaster recovery, not automatic high availability. TunGuard documents migration; I'm not claiming it currently provides automatic failover. You're identifying requirements for a highly available deployment, not disproving the value of centralised, per-peer DNS filtering. Those are different discussions.
