Managing a VPS from a home or office network sounds straightforward until your internet provider starts changing your public IP address.
That was one of the problems I ran into recently.
I had a VPS with some administrative resources restricted to specific IP addresses. The idea was simple: only my trusted IP should be able to access certain services.
The problem?
My ISP uses dynamic public IP addresses.
Every time my public IP changed, I potentially lost access to those IP-restricted resources.
Instead of continuously updating firewall rules whenever my IP changed, I decided to introduce Tailscale.
This article explains what Tailscale is, why it can be useful for VPS administration, and how to set it up on a Linux VPS and a Mac.
What is Tailscale?
Tailscale is a networking platform built around WireGuard that allows your devices and servers to communicate over a private network.
Tailscale calls this private network a tailnet.
Instead of relying on the public IP address of your VPS, devices connected to your tailnet can communicate using private Tailscale addresses, typically in the 100.x.x.x range.
For example:
Mac
|
| Tailscale
|
v
Private Tailnet
|
v
VPS
100.x.x.x
Tailscale describes itself as a zero-trust, identity-based connectivity platform, and it uses WireGuard for encrypted point-to-point connections.
The important part for me wasn't just encryption.
It was stable private connectivity between my devices and my VPS.
Why Would You Use Tailscale?
There are several reasons Tailscale can be useful.
1. Your ISP Uses Dynamic IP Addresses
This was my main reason.
Imagine you configure a firewall rule like:
Allow SSH
Source: 102.143.20.123/32
That means only that specific IP address can connect.
This is useful from a security perspective.
But if your ISP changes your public IP:
Yesterday:
102.143.20.123
Today:
105.131.95.49
your firewall rule is now outdated.
You have to manually update it.
With Tailscale, your Mac and VPS can communicate over your tailnet regardless of your ISP's current public IP.
Instead of depending on:
My ISP public IP
↓
VPS
you have:
My Mac
↓
Tailscale
↓
Private tailnet
↓
VPS
This means I can maintain stable private access without constantly updating IP allowlists because my ISP changed my public IP.
2. Secure Access to Your VPS
SSH is already encrypted, but exposing SSH to the public internet means your server is continuously reachable by internet scanners and automated login attempts.
Tailscale provides another way to access your server over your private tailnet.
For example:
ssh root@100.89.121.90
instead of:
ssh root@your-public-ip
The 100.82.128.80 address is a Tailscale address in this example.
Tailscale's documentation specifically supports using Tailscale to SSH into Linux machines over the tailnet.
3. You Don't Need to Know Your Current Public IP
Before using Tailscale, I might need to check my current public IP before accessing an IP-restricted service.
With Tailscale, my devices have stable identities on the tailnet.
That makes remote administration much more predictable.
4. Access Services That Shouldn't Be Public
Not every service running on a VPS needs to be accessible from the entire internet.
For example, you might have:
Public
├── HTTP :80
└── HTTPS :443
Private
├── Admin dashboard
├── Database administration
├── Internal monitoring
├── Development tools
└── SSH administration
Tailscale can be useful for the private portion.
Instead of exposing every administrative service publicly, you can make certain services reachable only through your tailnet.
5. You Can Connect More Than Just Your Laptop
Tailscale isn't limited to:
Mac → VPS
You can connect:
Mac
Laptop
Phone
VPS
Home server
Cloud server
Development machine
and control which devices can communicate with which resources.
Tailscale's access-control system is designed around identity and least-privilege access, allowing policies to define which users and devices can access specific resources.
Setting Up Tailscale on a Linux VPS
Let's walk through a basic setup.
I'm using an Ubuntu-based VPS for this example.
Step 1: Install Tailscale
On the VPS:
curl -fsSL https://tailscale.com/install.sh | sh
This is the installation method documented by Tailscale for mainstream Linux distributions.
After installation:
tailscale version
You should see the installed version.
For example:
1.102.3
Step 2: Authenticate the VPS
Run:
sudo tailscale up
Tailscale will provide an authentication URL.
Open the URL in your browser and authenticate with your Tailscale account.
Once completed, the VPS becomes part of your tailnet.
Step 3: Check the Tailscale Connection
Run:
tailscale status
You should see your VPS and other devices connected to your tailnet.
You can also retrieve the VPS's Tailscale IPv4 address:
tailscale ip -4
For example:
100.89.121.90
That address is what you can use for private communication with the VPS.
Step 4: Install Tailscale on Your Mac
Install Tailscale on your Mac and sign in using the same Tailscale account.
After both devices are connected, you should have something similar to:
Mac
100.x.x.x
|
| Tailscale
|
v
VPS
100.89.121.90
Step 5: Test SSH Through Tailscale
From your Mac:
ssh root@100.89.121.90
You can also explicitly specify an SSH key:
ssh -i ~/.ssh/your-key \
-o IdentitiesOnly=yes \
root@100.89.121.90
The important part is that the connection is going through the VPS's Tailscale address rather than its public IP.
Tailscale's documentation also supports using MagicDNS, allowing you to connect using a machine hostname instead of remembering the 100.x.x.x address.
Making SSH Easier with ~/.ssh/config
Typing the entire SSH command every time isn't necessary.
On your Mac:
nano ~/.ssh/config
Add:
Host my-vps
HostName 100.89.121.90
User root
IdentityFile ~/.ssh/your-key
IdentitiesOnly yes
Now you can simply run:
ssh my-vps
This becomes particularly useful when you have multiple servers and multiple SSH keys.
Tailscale vs a Traditional VPN
Tailscale is often described as a VPN, but the experience is different from configuring a traditional VPN server yourself.
With a traditional VPN setup, you might have to manage:
VPN server
Certificates
Routing
Firewall rules
NAT
Client configuration
Key management
Tailscale handles much of the networking complexity for you.
It uses WireGuard underneath and provides identity and access-control features around the network.
That's one reason it is attractive for developers and infrastructure administrators who don't want to manually build and maintain a VPN infrastructure.
Tailscale and Firewalls
One important thing to understand is that Tailscale does not automatically replace your firewall.
You can still use:
Contabo Firewall
↓
UFW
↓
Tailscale
↓
Application
Tailscale is designed to work alongside existing firewalls, and its networking can often work without additional firewall configuration because of NAT traversal.
Your firewall should still be configured according to what your server actually needs.
Should You Close Port 22?
This depends on your architecture.
If you use Tailscale exclusively for SSH, you can potentially remove public SSH access and use Tailscale SSH or SSH over the Tailscale network.
Tailscale's documentation even recommends closing the public SSH port after verifying Tailscale SSH access when appropriate.
However, this isn't always practical.
For example, if you have a CI/CD system using GitHub-hosted runners that connects to your VPS over public SSH, closing port 22 would break that deployment workflow unless you redesign the deployment architecture.
In that situation, you can keep port 22 publicly reachable while still using Tailscale for your own administrative access.
Tailscale SSH
Tailscale also has a feature called Tailscale SSH.
Instead of relying on traditional SSH key management, Tailscale can manage SSH authentication and authorization using your tailnet identity and access policies.
You can enable it with:
tailscale set --ssh
However, I recommend understanding your existing SSH setup before switching to Tailscale SSH on a production server.
You don't necessarily need Tailscale SSH just to benefit from Tailscale networking.
You can simply use:
Tailscale networking
+
Traditional SSH
which is the approach I used for my VPS.
A Practical VPS Security Architecture
A setup I like is:
Internet
|
+--------+--------+
| |
HTTPS SSH :22
| |
v v
Public Services VPS Firewall
|
v
SSH
^
|
Tailscale network
^
|
My Mac
Then I can keep public services public while using Tailscale for private administration.
For example:
Public
├── 80/tcp
└── 443/tcp
Restricted / Administrative
├── SSH
├── Admin interfaces
├── Internal tools
└── Monitoring
What Tailscale Doesn't Solve
Tailscale isn't a replacement for general server security.
You should still consider:
- SSH keys instead of passwords
- Disabling SSH password authentication
- Avoiding root for automated deployments
- Using dedicated deployment users
- Keeping the operating system updated
- Configuring a firewall
- Using least-privilege access
- Monitoring authentication attempts
- Using Fail2ban where appropriate
- Protecting application credentials
- Backups
Tailscale gives you a better networking and access layer; it doesn't magically make an insecure server secure.
My Main Takeaway
The biggest reason I added Tailscale to my VPS wasn't simply:
"I need a VPN."
It was:
"I need reliable private access to my infrastructure without depending on my ISP's changing public IP address."
That distinction matters.
If your ISP gives you a dynamic IP and you've built firewall rules around your current address, eventually you'll probably run into the same problem:
ISP changes IP
↓
Firewall rule becomes outdated
↓
Access breaks
↓
Update firewall
↓
ISP changes IP again
Tailscale changes the model:
Mac
↓
Tailscale identity
↓
Private tailnet
↓
VPS
Now my access doesn't depend on whatever public IP my ISP happens to assign me that day.
For anyone managing a VPS from a dynamic residential or office connection, Tailscale is worth considering.
It is particularly useful when you need private access to infrastructure without wanting to build and maintain a traditional VPN yourself.
Top comments (0)