Why this matters beyond the homelab: Remote desktop relay infrastructure is a real enterprise problem. RDP over VPN, Citrix, Azure Virtual Desktop, TeamViewer Enterprise: these all solve the same core problem with different tradeoffs around cost, control, and network dependency. Understanding why self-hosted relay wins in certain environments is the same reasoning behind choosing Azure Virtual Desktop in others.
The Problem
The Alliance Fleet needed a remote desktop solution for accessing Windows VMs from anywhere. Specifically Canto-Bight (VM 400, Windows 11 Pro, the gaming and AD test workstation) and ALLIANCE-DC01 (VM 300, Windows Server 2022) when not on the local network.
Tailscale already handles the network layer: every device in the tailnet can reach any fleet IP directly. So the question was not “how do I get remote access” but “what is the right protocol for remote desktop sessions over that tunnel.”
RDP over Tailscale works fine for direct connections when both the client and the server are in the tailnet. The gap is connecting from devices that are not enrolled in the tailnet, or from clients where RDP is blocked or unavailable.
RustDesk fills that gap: a cross-platform remote desktop client with its own relay infrastructure, fully self-hostable, free, and open source.
Why Not Azure Relay
The original plan included running the RustDesk relay on an Azure VM. The reasoning was portfolio value: another Azure workload, another piece of AZ-104 terrain.
That reasoning fell apart on inspection. Tailscale already handles NAT traversal for every device in the fleet. Running a relay server on Azure would mean:
- Paying for an Azure VM that duplicates functionality Tailscale already provides for free
- Remote desktop traffic routing through Azure (latency, cost, data leaving the fleet)
- Another service to maintain, patch, and monitor in a cloud account
The correct call was self-hosted on the fleet. Bothawui (CT 114) on Node-B costs nothing in Azure, keeps traffic inside the network when both endpoints are on Tailscale, and falls back to the self-hosted relay only when needed. The relay runs on infrastructure I own and monitor.
The Deployment
LXC container on Node-B:
| Field | Value |
|---|---|
| Container ID | CT 114 |
| Codename | (Bothawui) |
| Node | QCM1255 (Node-B, CR90 Corvette) |
| IP | 192.168.20.81 |
| VLAN | 20 (Naboo, Services) |
| OS | Debian 12 |
| RAM | 512MB |
| CPU | 1 core |
RustDesk server has two components: hbbs (the ID/rendezvous server) and hbbr (the relay server). Both run on the same CT.
Installation:
# Install RustDesk server
wget https://GitHub.com/rustdesk/rustdesk-server/releases/latest/download/rustdesk-server-linux-amd64.zip
unzip rustdesk-server-linux-amd64.zip
chmod +x hbbs hbbr
# Run as services (via systemd or PM2)
./hbbs -r 192.168.20.81 &
./hbbr &
The -r flag on hbbs tells the ID server where the relay is. Since both run on the same CT, the relay address is the CT’s own IP.
Client configuration:
In the RustDesk client settings, set the ID server to 192.168.20.81 and the relay server to 192.168.20.81. When both client and remote are on Tailscale, connections are peer-to-peer. When the relay is needed, traffic goes through CT 114 on Node-B instead of RustDesk’s public infrastructure.
Why Self-Hosted Wins Here
Three reasons this decision was correct for the fleet:
Cost: Zero. No Azure VM, no subscription, no bandwidth charges for relay traffic. A 512MB Debian LXC on existing hardware is essentially free.
Control: Traffic stays in the fleet. Remote desktop sessions between fleet machines do not touch a third-party relay. For ALLIANCE-DC01 and Canto-Bight, that means credentials and screen content stay inside the network.
Simplicity: Tailscale already handles the hard part (NAT traversal, authentication, encryption at the network layer). RustDesk adds the application-layer remote desktop protocol on top of that foundation. The two tools complement each other rather than overlap.
Uptime Kuma Monitor
CT 114 has an Uptime Kuma TCP monitor on port 21116 (the hbbs port). If the relay goes down, the alert fires to Discord before the next connection attempt fails silently.