A TeamViewer alternative: remote desktop over your own private network

What TeamViewer does very well

TeamViewer is a remote support and remote desktop tool: both ends install the vendor's software, and the vendor's infrastructure connects them. Its historical strength fits in a scene everyone knows: fixing the computer of someone you have never met. The person reads out an ID and a password displayed on their screen, you type them in, and you take control. No account to create on the helped side, no network to prepare, no shared configuration beforehand.

What gets in the way of some use cases

TeamViewer's qualities stem from an architectural choice: the vendor is the one connecting the machines. That choice is coherent for a universal support tool, but it has consequences worth knowing when what you want is permanent access to your own machines.

• The path goes through a third party. The brokering — and the relaying of traffic when the direct connection does not come through — is operated by the vendor’s servers. Access to your own machines therefore depends on the availability and rules of an external service, even when both machines are in the same room.
• The commercial-use policy. The tool is free for personal use, and the vendor detects usage it deems commercial: a session judged professional can be limited. It is a legitimate, openly stated policy — but the boundary can be delicate to live with when you fix the association’s computer, an occasional client’s PC, or your own work-from-home machine.
• A third-party agent and account on every machine. Every reachable machine runs the vendor’s software, and access rights live in an account hosted with them. Who may reach what is not a rule of your network: it is data held by the service.

The private-network approach: your machines talk to each other directly

The alternative is to stop going through a brokering service on every session, and instead build a private network between your machines once. Each machine is enrolled into your workspace, receives a stable private address and a readable name (MagicDNS), and becomes reachable by the other members as if they shared the same local network — wherever they physically are. Remote desktop and the terminal are then no longer a vendor's services: they are the standard protocols, RDP and SSH, travelling inside your own encrypted network.

The difference with a bastion or web gateway deserves emphasis. Those middleboxes terminate the SSH or RDP session on their server, which therefore holds the cleartext and your credentials, then forward the display to you. Here there is no intermediate termination: the protocol starts on your workstation — or in your browser tab — and ends on the target machine. The infrastructure carries opaque bytes; it does not read.

No third-party account in the loop — and no port to open

Replacing a brokering service must not bring back the chore everyone runs from: opening a port on the router, exposing port 3389 to the internet — one of the most attacked configurations there is, scanned continuously by bots. VIGIL-MESH asks for none of it: no node opens an inbound port. Every machine only establishes outbound connections, over a single flow on 443 UDP — the same port as the modern web, allowed outbound on nearly every network, including behind a consumer router or a 4G/5G connection on CGNAT.

1. 1
   Immediate connection through a relayAs soon as two machines need to talk, traffic goes through a relay (the vigie), itself reached outbound. No waiting: the RDP or SSH session opens right away.
2. 2
   NAT traversal looks for the direct pathIn parallel, the two machines try to establish a direct peer-to-peer path, without any port having been configured anywhere.
3. 3
   Seamless migrationAs soon as a direct path exists, the session migrates to it without reconnecting: your remote desktop does not even blink, the traffic simply changes route.

The relay deserves a word, because this is where the approach differs most from a support service: the vigie is structurally blind. It does not hold the session keys and carries end-to-end encrypted connections whose content it never sees. And if transiting through a shared relay bothers you, you can host your own private vigie, dedicated to your workspace: the relayed path then goes through a machine of yours.

Who this is the right choice for — and who TeamViewer remains better for

The entry cost of the private-network approach is simple to state: every machine must be enrolled once. It takes a few minutes per machine, but it assumes you have access to it and responsibility for it. This criterion settles almost every use case:

The two approaches are not mutually exclusive either: many people keep a support tool for the unexpected — a visiting friend's laptop — and run their own machines on their private network. These are two different problems, and it is healthy to solve them with two different tools.

A fleet of machines: workshop, managed family, small team

The private-network approach shows its full value as soon as there are more than two machines, because it turns a pile of one-off sessions into an administered network. Three concrete examples:

• The workshop. The workstations driving the machines, the drawings server and the industrial gateway are enrolled. From the office — or from a browser on the road — you open a desktop on the milling machine’s workstation or a terminal on the gateway, by name, while none of those machines is reachable from the internet.
• The managed family. During a visit, you enroll the parents’ PC once. From then on, every fix is an ordinary remote desktop session to a machine of your own network — no ID to have read out over the phone, no limited session, nothing to reinstall.
• The small team. Workstations and servers live in the same workspace. Everyone reaches their own machines; the administrator reaches everything; the contractor sees a single machine, on a single port.

That last point rests on access policies (ACLs), and it is what separates an administered network from a mere contact list: deny by default. What is not explicitly allowed is forbidden, and the rules speak of identities — machines, groups, tags —, never of addresses:

Setting up your network, step by step

The setup happens once, machine by machine. The client exists for Windows, Linux, Android and NVIDIA Jetson — and the browser can become an ephemeral node through the console, with nothing to install.

1. 1
   Create an account and a workspaceThe workspace is the perimeter where your networks, machines and access rules will live.
2. 2
   Install the client on the machines involvedThe Windows workstation you want to reach over RDP, the server to administer over SSH, the laptop you work from.
3. 3
   Enroll each machineNetworks page → Machines → “Add a machine”: the wizard hands you a one-time enrollment key, passed to the client as a command or as a QR code on mobile. The machine generates its identity locally and opens no inbound port.
4. 4
   VerifyThe machine appears in the console with its stable address; a ping or its MagicDNS name confirms it is reachable.
5. 5
   Connect as if localRemote desktop to the Windows workstation's name, SSH to the server's name — or a terminal from the console's Administration tab. The ACLs decide who may administer what.

Frequently asked questions