How I Rebuilt My Remote Access Stack for Free with Tailscale, RustDesk, and RDP

The Problem: NordVPN Killed My Remote Access

I had a working remote desktop setup across multiple machines in my home lab and a managed device I access remotely. Then I turned on NordVPN for privacy while browsing, and everything stopped working. My RDP connections dropped, and I could not reach any of my machines remotely.

The core issue was straightforward: a traditional VPN encrypts and reroutes all traffic through a remote server. That breaks direct connections between devices on the same local network or across the internet. Public-IP-based RDP relies on knowing the target machine's real IP address and having the right ports forwarded on the router. NordVPN masked all of that.

Instead of just turning NordVPN off and going back to exposed port forwarding, I decided to find a better architecture. One that would give me privacy, remote access, and security without paying for anything.

What I Tested

I evaluated three different remote access paths, all free, and tested each one across my primary workstation (Windows), a managed Windows device, and my mobile device (iOS).

1. Nord Meshnet + RDP

NordVPN includes a feature called Meshnet that creates a private encrypted network between your devices. Each device gets a stable Meshnet IP address, and you can use that IP for RDP instead of a public IP.

My first attempt failed, and I initially blamed the product. But after more debugging, I discovered the real cause: I had a typo in the Meshnet IP address. Once I used the correct IP, Nord Meshnet + RDP worked fine. Lesson learned: always double-check the connection target before blaming the tool.

2. Tailscale + RDP

Tailscale is a mesh VPN built on WireGuard. You install it on each device, sign in, and every device gets a stable 100.x.x.x IP on your private Tailscale network. No port forwarding, no public IP exposure, no configuration on the router.

I installed Tailscale on my primary workstation and the managed device, and RDP connected instantly using the Tailscale IP. The connection was fast and stable. Tailscale uses NAT traversal to establish direct peer-to-peer connections whenever possible, and falls back to relay servers (called DERP) only when direct connections are not possible.

For Windows-to-Windows remote access, Tailscale + RDP is the fastest and most efficient option because RDP is native to Windows and optimized for its desktop rendering.

3. RustDesk + Tailscale

RustDesk is an open-source remote desktop tool similar to TeamViewer or AnyDesk, but free and self-hostable. I did not self-host it. Instead, I installed the RustDesk client on all my devices and connected them through the Tailscale network.

This combination worked smoothly across all my devices, including from my phone. RustDesk handles the remote desktop protocol, and Tailscale handles the private networking layer. Together, they gave me cross-platform remote access without exposing anything to the public internet.

What Worked and Why

All three paths technically worked, but each has a different sweet spot:

• Tailscale + RDP: Best for Windows-to-Windows connections. Fastest performance, native rendering, and the most responsive experience. Use this when both machines are Windows.

• RustDesk + Tailscale: Best for cross-platform access. Works from iOS to Windows, Windows to Linux, or any OS combination. Slightly less efficient than native RDP, but far more flexible.

• Nord Meshnet + RDP: Works, but only useful if you already pay for NordVPN. Tailscale does the same thing better and for free.

One important limitation I confirmed: iOS devices cannot be remotely controlled by any of these tools. Apple restricts third-party remote control of iOS at the OS level. RustDesk can use an iPhone as a controller to access other machines, but you cannot remote into an iOS device. The only Apple-supported exception is FaceTime remote control between Apple devices on iOS 18+, which is limited and not the same as full remote desktop.

Why I Did Not Self-Host

RustDesk supports self-hosting your own relay and signaling server. People do this for more control over privacy, to eliminate dependency on public infrastructure, or to manage large fleets of devices.

I skipped it for a simple reason: Tailscale already gives me a private network with NAT traversal and encrypted connections. Adding a self-hosted RustDesk server on top of that would be redundant complexity. I wanted a zero-cost, low-maintenance setup. Self-hosting a VPS, maintaining updates, and managing uptime adds cost and toil that I do not need right now.

The rule is simple: if you need it working free and fast, do not self-host. If you later need full ownership for a team or business, self-host then.

Security: Closing Exposed Router Ports

Before this project, I had port 3389 (RDP) forwarded on my home router so I could connect remotely over the public internet. That is a well-known attack surface. Port 3389 is one of the most commonly scanned and targeted ports on the internet.

With Tailscale handling connectivity through NAT traversal, I no longer need any router port forwards for remote access. I closed:

• Port 3389 (RDP) on the router

• Port 21118 (RustDesk direct IP) if previously opened

• Ports 21115-21117 (RustDesk server components) if previously opened

This is a meaningful security improvement. Moving from public port forwarding to private overlay networking eliminates an entire class of exposure. The machines are still fully accessible to me through Tailscale, but invisible to the public internet.

The Managed Device RDP Policy Trap

After getting Tailscale + RDP working between my personal machines, I tried the same setup with a managed Windows device. It failed with error 0x1307: restricted logon type.

I went through a full debugging process:

1. Confirmed the account type with whoami and net user. It was a local Windows account, not a domain or Azure AD account.

2. Discovered the account used a PIN, not a password. But the real password did exist (Settings showed "Change" not "Add").

3. Added the user to Remote Desktop Users group via lusrmgr.msc. Still failed.

4. Checked secpol.msc and found the blocker: Deny log on through Remote Desktop Services included Local account.

This is a Microsoft security baseline policy designed to prevent pass-the-hash attacks against local administrator accounts over the network. It is the right policy for a managed machine. The practical effect is that the local account will never be allowed to connect via RDP while that policy is in place, regardless of password or group membership.

Since this is a managed device with organization-enforced settings, the correct decision was to not fight the policy. I use RustDesk for that device instead, which bypasses the RDP restriction entirely because it uses its own protocol.

Final Setup and Recommendation

Here is the final architecture I landed on:

• Primary remote access: RustDesk + Tailscale for all cross-platform connections

• Windows-to-Windows fast path: Tailscale + RDP for best native performance

• Privacy and browsing: NordVPN stays installed but is not used as a remote access foundation

• Managed device: RustDesk only, since RDP is blocked by organization security policy

• Mobile: Can control other machines via RustDesk, but cannot be controlled remotely (iOS restriction)

What I do not need:

• No paid plans

• No public port forwarding

• No VPS or self-hosted servers

• No router configuration beyond closing old port forwards

Key Takeaways

1. Traditional public-IP RDP with port forwarding is fragile and risky. Overlay networks like Tailscale eliminate the need for it entirely.

2. RDP is the best Windows remote desktop protocol, but it is Windows-only. RustDesk fills the cross-platform gap cleanly.

3. Organization security policies exist for good reasons. When RDP is blocked by policy, work around it with a different protocol rather than fighting the policy.

4. Close router port forwards once you move to private networking. Every open port is attack surface you no longer need.

5. Self-hosting is optional, not required. For personal use, the free tiers of Tailscale and RustDesk public infrastructure are more than enough.

6. Always verify your connection details before blaming the tool. My first Meshnet failure was a typo, not a product defect.

The entire setup costs nothing, requires no infrastructure I have to maintain, and is more secure than what I had before. Sometimes the best engineering solution is the one that removes complexity instead of adding it.