Remote Access Evolution: From TeamViewer to Tailscale

Two separate problems. Years of conflating them.

Problem 1: Help family members with tech support. See their screen, fix their printer, explain where to click.

Problem 2: Access my own infrastructure remotely. SSH into servers, reach internal services, work from anywhere.

I kept trying to solve both with the same tool. That was my first mistake.

The Remote Help Problem

This one came first. My parents needed help. My in-laws needed help. Everyone needed help with something.

TeamViewer (2014-2018)

The appeal: Install it, get a code, connect from anywhere. Zero network knowledge required for the person you’re helping.

What worked:

Dead simple setup
Punched through any NAT/firewall
Screen sharing, file transfer, chat
Cross-platform

What killed it:

The commercial use detection. I wasn’t using it commercially—I was helping my parents fix their printer. But TeamViewer disagreed. Connections started getting cut off after 5 minutes with “Commercial use suspected.”

The appeal process was a joke. Submit forms, wait weeks, get rejected. Repeat.

Then there were the security incidents. TeamViewer had multiple breaches where attackers gained access to user accounts. Not ideal for something with permanent access to your machines.

Cost to fix commercial detection: $50/month (TeamViewer Business)

Did I pay it? No. I left.

AnyDesk (2018-2022)

Why I switched: No commercial use detection (at the time). Faster protocol. Lighter footprint.

What worked:

Genuinely faster than TeamViewer
Lower latency—felt almost usable for actual work
Simple interface
Free for personal use (actually free)

What failed:

The reliability. Connections dropped randomly. Not often, but often enough to be annoying mid-session.

The platform support. Linux support was… functional. The GUI was clearly an afterthought.

The trust issue. After TeamViewer’s security problems, I realized: I’m giving a third-party company permanent access to family machines. The connection goes through their servers. I don’t control the encryption. I don’t control the logs.

For family tech support, it was fine. But I started wanting something self-hosted.

RustDesk (2022-Present)

The self-hosted solution. Open source remote desktop with an optional self-hosted relay server.

My setup:

RustDesk server on a VPS (public IP)
RustDesk clients on family machines
Traffic relays through my VPS

What works:

Self-hosted (no third-party data concerns)
Works through any NAT
Good performance
Open source

The limitations:

It’s remote desktop, not network access. I can see screens. I can’t SSH through it. I can’t access internal services.

The VPS overhead. $5/month for a relay server I only use occasionally.

But for family tech support? It’s perfect. That problem is solved.

The Infrastructure Access Problem

This was the harder one. Accessing my own network from anywhere.

Era 1: Port Forwarding + Dynamic DNS (Early Days)

The naive approach: Open ports directly. Use Dynamic DNS to track my home IP.

The setup:

Forward port 22 (SSH) on router
Forward port 3389 (RDP) for Windows machines
DuckDNS to track my home IP

What worked:

No third party involved
Native SSH/RDP performance
I controlled everything

What failed:

Security. Port 3389 open to the internet is a terrible idea. Within hours of enabling it, I saw brute force attempts in the logs. Thousands of them. From everywhere.

Mitigation attempts:

Changed RDP port to non-standard → Attackers found it anyway
Implemented fail2ban → Helped, but didn’t stop everything
Closed RDP entirely, kept only SSH with key auth

SSH with key-based auth worked, but I was still exposing services directly to the internet. One zero-day away from compromise.

Era 2: WireGuard (July-August 2025)

After years of just using SSH, I finally tried a proper VPN. WireGuard appealed because of its simplicity.

The setup:

[Interface]
PrivateKey = <generated>
Address = 10.200.200.1/24

[Peer]
PublicKey = <my-phone>
AllowedIPs = 10.200.200.2/32

[Peer]
PublicKey = <my-laptop>
AllowedIPs = 10.200.200.3/32

That’s the whole server config. Clean.

What worked:

Blazing fast (UDP only, kernel-level)
Simple configuration
Stable connections
Low overhead

What failed:

Still needed port forwarding. I had to expose UDP 51820 to the internet. Not as scary as RDP, but still a public endpoint.

CGNAT. When I traveled, hotel WiFi and cellular networks often had their own NAT layers. WireGuard doesn’t punch through NAT well.

Peer management. Adding a new device meant editing the server config and restarting. For a few devices, fine. For 10+ devices, tedious.

No discovery. If my home IP changed, connections failed until I updated configs everywhere.

WireGuard was better than raw port forwarding. But the operational overhead was still significant.

Era 3: Tailscale (November 2025-Present)

I’d heard about Tailscale for a while. Kept dismissing it as “just another VPN service.”

Then I tried it.

The setup:

curl -fsSL https://tailscale.com/install.sh | sh
tailscale up

That’s it. On every device. No port forwarding. No certificates. No key management. No VPS.

What Tailscale actually is:

Tailscale is a mesh VPN built on WireGuard. But instead of manually configuring peers, Tailscale’s coordination server handles it.

Devices authenticate via SSO (Google, GitHub, etc.)
Coordination server tells devices how to find each other
Devices connect directly (peer-to-peer) when possible
Traffic never goes through Tailscale’s servers (except for DERP relay when direct connection fails)

The magic: NAT traversal.

Tailscale implements NAT traversal that actually works. STUN, TURN, hole punching—all the techniques that make WebRTC work, applied to VPN connections.

My phone on cellular. My laptop on coffee shop WiFi. My home server behind CGNAT. All connected directly.

What finally worked:

Everything.

Feature	WireGuard	Tailscale
Port forwarding needed	Yes	No
Works through CGNAT	No	Yes
Auto peer discovery	No	Yes
Device management	Manual	Web UI
Mobile app	Manual config	Just works
ACLs	None	Built-in
Setup time	30 min	2 min

Subnet Routing: The Full Picture

Tailscale on every device is fine. But what about devices that can’t run Tailscale? IoT devices. NAS units. Printers.

Subnet routing lets a Tailscale node advertise access to an entire local subnet.

tailscale up --advertise-routes=10.42.0.0/24

Now any Tailscale device can access 10.42.0.0/24 through that node.

My setup:

┌─────────────────────────────────────────────────────────────────┐
│                       TAILSCALE MESH                            │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  ┌────────────────┐         ┌────────────────┐                  │
│  │ My Phone       │◄───────►│ My Laptop      │                  │
│  │ (Tailscale)    │         │ (Tailscale)    │                  │
│  └────────┬───────┘         └───────┬────────┘                  │
│           │                         │                           │
│           │    Direct mesh connection                           │
│           │                         │                           │
│  ┌────────┴─────────────────────────┴────────┐                  │
│  │              Subnet Router                 │                  │
│  │         (gateway-Altair)           │                  │
│  │                                            │                  │
│  │  Advertises: 10.42.0.0/24                  │                  │
│  └────────────────────┬───────────────────────┘                  │
│                       │                                          │
│                       │ (Physical network)                       │
│                       │                                          │
│  ┌────────────────────┴───────────────────────┐                  │
│  │           LOCAL NETWORK (10.42.0.0/24)     │                  │
│  │                                            │                  │
│  │  ┌──────────┐ ┌──────────┐ ┌──────────┐    │                  │
│  │  │ NAS      │ │ Printer  │ │ IoT      │    │                  │
│  │  │10.42.0.10│ │10.42.0.20│ │10.42.0.30│    │                  │
│  │  └──────────┘ └──────────┘ └──────────┘    │                  │
│  └────────────────────────────────────────────┘                  │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

From my phone in a hotel room, I can access 10.42.0.10 (my NAS) as if I was on my home network.

The LXC Routing Challenge

Running Tailscale in a Proxmox LXC container requires some kernel-level tweaks. LXC containers share the host kernel, which means certain network operations need explicit permission.

The problem: Subnet routing didn’t work initially. Packets came in via Tailscale but responses went out the default gateway.

The solution: Source-based routing.

# /etc/network/if-up.d/tailscale-routes
#!/bin/bash
sleep 5

# Add routes to custom table
ip route add 10.42.0.0/24 dev eth0 src 10.42.0.199 table 52 2>/dev/null || true

# Rule: traffic from Tailscale uses table 52
ip rule add iif tailscale0 lookup 52 prio 100 2>/dev/null || true

Traffic entering via Tailscale now exits via Tailscale. Asymmetric routing fixed.

ACLs: Security by Default

Tailscale’s ACL system is how you control who can access what.

My policy:

{
  "tagOwners": {
    "tag:server": ["[email protected]"],
    "tag:gateway": ["[email protected]"]
  },
  "acls": [
    // I can access everything
    { "action": "accept", "src": ["[email protected]"], "dst": ["*:*"] },

    // Family can only access specific services
    { "action": "accept", "src": ["group:family"], "dst": ["10.42.0.10:*"] },

    // Gateways can route
    { "action": "accept", "src": ["tag:gateway"], "dst": ["*:*"] }
  ],
  "autoApprovers": {
    "routes": {
      "10.42.0.0/24": ["tag:gateway"]
    }
  }
}

Family members can access the NAS but nothing else. I can access everything. Servers can only talk to each other if explicitly allowed.

The Two-Stack Solution

For family tech support: RustDesk (self-hosted)

Screen sharing when needed
No permanent access
Works through any NAT
Self-hosted relay

For infrastructure access: Tailscale

Full network access
Zero maintenance
Works everywhere
Native protocols (SSH, etc.)

Don’t conflate the problems. Remote help and infrastructure access are different needs with different solutions.

The Result

Before Tailscale (November 2025):

Port forwarding headaches
WireGuard configs to maintain
CGNAT problems when traveling
Manual peer management

After Tailscale:

2 minutes to set up a new device
Free tier covers all my devices
Zero maintenance
Just works

Latency test (Milky Way to Andromeda):

Physical distance: 40 miles
Latency: 38ms
Bandwidth: Full line speed

It’s not going through Tailscale’s servers. It’s direct, peer-to-peer, encrypted with WireGuard.

What I’d Tell Past Me

Separate the problems. Remote help for family is different from infrastructure access. Use different tools.

Don’t fight NAT. You will lose. Use a solution that handles it for you.

WireGuard is great, but operational overhead matters. The protocol is excellent. Managing peers and handling NAT is still painful.

Tailscale isn’t “just another VPN.” It’s what VPNs should have been from the start.

Current Status

Need	Solution
Family tech support	RustDesk (self-hosted)
Full network access	Tailscale mesh
SSH	Native (via Tailscale)
Internal services	Native (via Tailscale subnet routing)

Everything infrastructure-related goes through Tailscale. RustDesk handles the occasional family “my printer isn’t working” call.

Two problems. Two solutions. Finally solved.