Tailscale runs the coordination server so you never have to. QS-WAN hands you that job on purpose: the control tower runs on your own infrastructure, including air gapped. Move if the thing that decides who joins your network has to sit inside your boundary. Stay if it does not, because their install is faster than ours.
Tailscale builds a peer to peer mesh over WireGuard, a tailnet, with “each device connected to the other directly”. Their engineering post calls the coordination server “essentially, a shared drop box for public keys”: the control plane is hub and spoke, the data plane is a mesh. Identity is not theirs either. They “always outsource authentication to an OAuth2, OIDC, or SAML provider”.
What they are good at is not small.
They get machines that were never meant to reach each other talking, without anybody drawing a network.
NAT traversal uses STUN and ICE, with DERP relays that “blindly forward already encrypted traffic” as the fallback.
You install the client, log in, and it works before the kettle boils.
Who runs the thing that decides who is allowed onto your network?
Their own documentation puts the consequence plainly: “Inherently, customers must trust Tailscale’s control plane to make the right decisions about who and what can join any given tailnet.” Tailnet Lock shrinks that trust by making a node you own sign new additions, and their open source page lists the coordination server as closed source.
The diagram compares two control plane architectures. A dashed box marks your network boundary and holds a laptop, a cloud instance and an office LAN. In the first, the coordination server that decides which devices may join sits outside that boundary, so the control channel from each machine crosses the line to reach it, and nothing there is yours to patch. In the second, the control tower runs inside the boundary, so enrolment, certificate issuance and the signed company policy all stay on your side of the line, and patching and backups become your job. The identity provider sits outside in both, because both delegate authentication to an OIDC or SAML provider. The diagram compares control planes only and says nothing about how traffic moves between machines.
In QS-WAN the control tower is software you run, on premise, in a private cloud or air gapped, so enrolment, key exchange, certificate issuance and policy signing all happen inside your boundary. The key exchange is hybrid post quantum, X25519 plus ML-KEM-768, with ML-DSA-87 authentication and AES-256-GCM. Crypto agility is operational: eight key exchange options, eight certificate authorities and three ciphers, switchable fleet wide or per gateway, with the certificates re-signed for you.
It hands you a bill, too. Patching, backups and availability are yours now, and Tailscale does all of that for you.
Theirs is the tailnet policy file, huJSON, edited in the console or by API. Ours is a signed company policy of 16 rules, scoped per gateway, user or device, where an override changes only the ids it sets.
You create VLANs and LANs, reserve their address ranges and draw the edges between them. Zero trust is a separate control from the tunnel mode, so a VLAN can run split tunnel and still be default deny, and every edge shows up on the map of your segments.
Their DNS gives MagicDNS, global nameservers and split DNS, with category filtering from an outside resolver. Here a DNS profile is assigned per VLAN and filters by category against 4.8 million domains, counted on 2 September 2026.
Their docs are specific: traffic keeps flowing and cached rules keep being enforced, but “existing users cannot have their keys revoked”. Ours is the same shape, except the uptime target is yours: with the Tower Connection off, edits save but are not pushed, and the console says so.
Tailscale does have device posture, and it is real: operating system version, geolocation for the public IP, and attributes from posture integrations, all usable in access rules.
That is conditional access, and it decides whether a device gets in, not what happens to something already running on it.
That is where the agent changes shape. One signed install carries the tunnel plus endpoint protection with EDR, remote support, a password vault and encrypted file transfer, and USB port blocking is one of those 16 rules.
We are not a security operations centre, though. Nobody of ours watches your traffic.
The specific cost of leaving a tailnet is names and routes, not packets. Every MagicDNS name your scripts and runbooks use is a name that exists because the coordination server hands it out, and the subnet routes an exit node advertises are decisions recorded in their console rather than in your addressing plan.
So the migration is really an inventory: which names are load bearing, and which routes somebody added on a Tuesday and never wrote down.
You stand the tower up on your own infrastructure, put a gateway beside the LANs you already have, and run both networks in parallel while those names move. Budget for the inventory, not for the cutover.
If you need laptops and cloud instances reachable from anywhere, and nothing in your compliance file cares where the control plane lives, Tailscale is doing the job, and replacing it for an agent you did not ask for is a bad trade.
A huJSON file reviewed in a pull request is a good workflow, and ours is a console with scope and overrides instead.
Windows is the complete column, macOS is shipping with CIS benchmarks running against real hosts, and Android is there. Linux has gaps and iOS is next rather than now.
Consolidation only pays when it removes contracts. If yours has two years left, the arithmetic does not work.
One where the control plane runs with no route to the internet. Tailscale's docs say customers must trust their control plane to decide who joins a tailnet. The QS-WAN control tower runs on your own infrastructure instead, which is what makes air gapped networking possible.
Yes, and so does Tailscale, which delegates authentication to an OAuth2, OIDC or SAML provider. The difference is not where identity comes from, it is where the decision to admit a device is made and signed.
Running. Hybrid key exchange, X25519 plus ML-KEM-768, with ML-DSA-87 authentication and AES-256-GCM, aligned to FIPS 203, FIPS 204 and CNSA 2.0. Hybrid by design means the security is never worse than the classical baseline.
Somebody else's operations team. Patching, backups and availability become yours. You get that back in keys and policy that never leave your boundary.
We will show you where the tower would sit on your own layout, free, with nothing to sign and no clock running.
