Understand the problem Tailscale solves

A traditional remote-access VPN usually sends clients through one gateway. You must expose, patch, scale, and route that gateway before two private devices can communicate.

That gateway is a single point of failure and a public attack surface. It also shapes your traffic: two laptops in the same city may talk through a datacenter on another continent. Every new device means more certificates, more routing rules, more firewall changes.

What makes private connectivity hard

Most of your devices sit behind NAT. Your laptop has a private address on your home Wi-Fi. Your server may sit behind a cloud firewall. Neither can accept an inbound connection unless you forward ports or expose services publicly.

The classic workaround looks like this:

# expose SSH publicly and hope the firewall rules hold
ssh [email protected] -p 22022

You changed the port, added fail2ban, maybe restricted source IPs. You are still running a public service, and you maintain that protection forever.

What Tailscale changes

Tailscale creates an identity-aware overlay network called a tailnet. Devices keep their existing Internet connections, then use Tailscale addresses and policies for private communication. You do not open an inbound port on every laptop or move all traffic through one central server.

Each device authenticates with your identity provider, gets a stable private address, and builds encrypted WireGuard tunnels directly to the peers it needs. The same SSH connection becomes:

ssh flavio@lab-server
# no public port, no port forwarding, no central gateway

The server’s public firewall can drop every inbound packet, and this still works, because both sides connect outward.

Try it

Draw your laptop, one server, their ordinary Internet paths, and the private path you want between them. Mark which public ports you would otherwise need to expose.

If the answer is “SSH on the server, and maybe a web dashboard”, you found exactly what a tailnet removes from the public Internet.