Tailscale on a VPS: Your Own Exit Node in Amsterdam or Dublin, Subnet Router and SSH

A Tailscale exit node on a VPS sends all of your internet traffic through that server, so the websites you visit see the VPS's fixed IP address instead of the hotel Wi-Fi or your mobile carrier. You install Tailscale on the VPS, switch on IP forwarding, run tailscale up --advertise-exit-node, approve the server once in the admin console, and then pick it as the exit node on your phone or laptop. The same private network, which Tailscale calls a tailnet, can also reach your home lab through a subnet router and lets you log in to the server with Tailscale SSH, all on the free Personal plan. We built the whole setup in our lab on 9 October 2026 and show every command with the output we got.

Key facts, checked on 9 October 2026:

• Tailscale 1.104.1 is the current stable client, released on 7 October 2026 (Tailscale changelog). The official install script set it up in 6 seconds per machine in our lab.
• The Personal plan costs $0 for up to 6 users with unlimited user devices; Standard is $8 and Premium $18 per user per month (Tailscale pricing). These prices came with the pricing change of 8 April 2026, which also retired the Personal Plus plan (Tailscale blog).
• The docs say "Exit nodes are available for all plans", and the same holds for subnet routers and Tailscale SSH (exit node docs).
• Device keys expire after 180 days by default, which logs a server out of the tailnet unless you turn expiry off for it (key expiry docs).
• Tailscale says it passed 10,000 business customers in January 2025 (Tailscale blog) and raised a $160 million Series C in April 2025 (Tailscale blog).

The hotel Wi-Fi problem

You are in a hotel in Milan, or on a train with your phone as a hotspot. Your bank app wants extra verification because you suddenly appear from an Italian mobile network. A work dashboard only accepts one whitelisted address. And the NAS and the Home Assistant panel sit on your LAN at home, behind a router with no open ports.

A classic VPN to a server fixes the first two but does not get you into the house, and opening ports at home invites the whole internet to knock on them. Tailscale handles all three with one small VPS and a Raspberry Pi at home, with no port forwards.

What Tailscale actually is, in plain words

Tailscale is a mesh VPN built on WireGuard, the fast and simple VPN protocol that is part of the Linux kernel. Every device runs a small program, tailscaled, and gets a private address from the 100.64.0.0/10 range. A coordination server (Tailscale's own service, or Headscale if you host it yourself) hands out keys and tells devices how to find each other. The traffic itself goes directly from device to device, encrypted end to end; when that fails behind strict NAT, a DERP relay forwards the already encrypted packets. Tailscale puts it plainly: "Your decrypted traffic never passes through any servers controlled by us" (Tailscale blog, August 2025). The coordination service does know your device names, addresses and which devices talk to which.

Three Tailscale features turn a VPS into a useful travel companion:

Amsterdam, Dublin or Prishtina: which city for the exit node

An exit node gives you the IP address of the city it sits in. Pick the city by what you need the address for:

• Amsterdam gives you a Dutch address in one of Europe's best connected internet hubs. When we ran tailscale netcheck from our Amsterdam test server, the nearest DERP relay was Amsterdam at 1.3 ms, with London at 5.6 ms and Frankfurt at 6.8 ms (DERP regions).
• Dublin gives you an Irish address, which helps when a service or a company firewall rule expects an Irish or EU connection. Tailscale has no DERP relay in Dublin; London is the closest, which only matters when a direct connection fails.
• Prishtina gives you an address in Kosovo. For people from Kosovo who live or travel abroad, that is the closest thing to being on a home connection.

Two small VPS plans, say one in Amsterdam and one in Prishtina, show up as two exit nodes in the same menu, one tap apart. Availability by city is on the plans page.

How we tested it

We could not sign in to Tailscale's hosted service from a lab, so we ran the open-source Headscale 0.29.4 (released 23 September 2026) as the coordination server on our Amsterdam test server. If you would rather keep running your own control server, our Headscale and NetBird comparison goes deeper. Four Debian 13 containers played the parts: the Headscale server, the VPS (tailnet name ams-vps), a Raspberry Pi at home (home-pi, with a fake home LAN 192.168.50.0/24 and a "NAS" at 192.168.50.10), and a laptop in a hotel. Each container had 2 shared vCPUs and Tailscale 1.104.1.

The Tailscale commands are the same on the hosted service. The only difference is that we added --login-server http://10.141.188.190:8080 to tailscale up so the clients talked to our Headscale instead of Tailscale's servers. Below we show the hosted versions, run as a normal user called riad with sudo rights.

Step 1: install Tailscale on the VPS

Log in to your new VPS over SSH as your normal user (create one with adduser and add it to the sudo group if you only have root). Then run the official script from the Linux install docs, which adds Tailscale's package repository.

# as riad (normal user with sudo) on the VPS
sudo apt-get update && sudo apt-get install -y curl
curl -fsSL https://tailscale.com/install.sh | sh
tailscale version

Expected output (the end of it):

# output we saw
Installation complete! Log in to start using Tailscale by running:

sudo tailscale up
1.104.1

Step 2: make the VPS a Tailscale exit node

An exit node forwards packets from your devices to the internet, so Linux must be allowed to forward traffic. These three lines come straight from Tailscale's subnet router docs and survive a reboot:

# as riad on the VPS
echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

Expected output:

# output we saw
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1

Now connect the VPS to your tailnet, offer it as an exit node and switch on Tailscale SSH in one go:

# as riad on the VPS
sudo tailscale up --advertise-exit-node --ssh

The command prints a login link and waits. On Tailscale's service the link starts with https://login.tailscale.com/a/; open it in the browser on your own computer, sign in with your Google, Microsoft, GitHub or other account, and the VPS joins your tailnet. Our run against Headscale printed this:

# output we saw (Headscale prints its own address instead of login.tailscale.com)
Warning: UDP GRO forwarding is suboptimally configured on eth0, UDP forwarding throughput capability will increase with a configuration change.
See https://tailscale.com/s/ethtool-config-udp-gro

To authenticate, visit:

	http://10.141.188.190:8080/register/hskey-authreq-HjrjjESGdp3N6mFcs3p8hroy

Success.

Advertising an exit node is only an offer, and an admin has to accept it: open the Machines page in the admin console, find the VPS with the Exit Node badge, open its menu, choose Edit route settings and switch on Use as exit node. If you add yourself to autoApprovers in the access policy, future exit nodes are approved automatically (exit node docs).

Give the server a short name, which becomes its MagicDNS hostname:

# as riad on the VPS
sudo tailscale set --hostname=ams-vps

Fix the UDP GRO warning

GRO (generic receive offload) lets the network card hand the kernel UDP packets in large batches instead of one at a time. Tailscale's performance guide recommends this change for exit nodes and subnet routers on Linux kernel 6.2 or newer; Debian 13 ships 6.12. In Tailscale's own tests the related work raised UDP throughput about four times (Tailscale blog, 2023).

# as riad on the VPS
sudo apt-get install -y ethtool networkd-dispatcher
NETDEV=$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")
sudo ethtool -K $NETDEV rx-udp-gro-forwarding on rx-gro-list off
sudo ethtool -k $NETDEV | grep -E "udp-gro-forwarding|rx-gro-list"

Expected output:

# output we saw
rx-gro-list: off
rx-udp-gro-forwarding: on

The setting is lost on reboot. If your server uses systemd-networkd (systemctl is-active systemd-networkd prints active), this script from the same guide re-applies it whenever the network comes up:

# as riad on the VPS
printf '#!/bin/sh\n\nethtool -K %s rx-udp-gro-forwarding on rx-gro-list off \n' "$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")" | sudo tee /etc/networkd-dispatcher/routable.d/50-tailscale
sudo chmod 755 /etc/networkd-dispatcher/routable.d/50-tailscale

After a restart, GRO forwarding and IP forwarding were still on, Tailscale was back online, and the warning was gone.

Step 3: use the exit node from the hotel

On a phone or a Windows or Mac laptop, open the Tailscale app, tap Exit node and choose ams-vps. On Linux it is one command. First check that the exit node is on offer:

# as riad on the laptop
tailscale status

# output we saw
100.64.0.3  laptop   riad  linux  -
100.64.0.1  ams-vps  riad  linux  idle; offers exit node
100.64.0.2  home-pi  riad  linux  -

# as riad on the laptop
sudo tailscale set --exit-node=ams-vps
tailscale status
curl -4 https://ifconfig.me

# output we saw
100.64.0.3  laptop   riad  linux  -
100.64.0.1  ams-vps  riad  linux  active; exit node; direct 10.141.188.45:41641, tx 5936 rx 8824
100.64.0.2  home-pi  riad  linux  active; direct 10.141.188.103:41641, tx 1944 rx 1816
217.60.96.72

The word direct matters: the laptop talks to the VPS straight over WireGuard, not through a relay. On a real trip, ifconfig.me shows the hotel's address before and the VPS's address after. In our lab every container shares the test server's public IPv4 (217.60.96.72), so the address looks the same either way. The proof was on the VPS: its connection tracking table showed the laptop's request to ifconfig.me arriving from tailnet address 100.64.0.3 and leaving with the VPS's own address.

Why the hotel printer disappears

With an exit node on, your device can no longer reach the local network it sits on, so other guests on the hotel Wi-Fi cannot see you. In our lab, a web server on the laptop's own LAN stopped answering the moment the exit node went on. If you need the local printer, allow it:

# as riad on the laptop
sudo tailscale set --exit-node=ams-vps --exit-node-allow-lan-access=true

The LAN server answered again. To stop using the exit node, set it to nothing:

# as riad on the laptop
sudo tailscale set --exit-node=

Step 4: reach the house with a subnet router

A subnet router is a tailnet device that says "send me the traffic for this LAN and I will deliver it". Put Tailscale on a Raspberry Pi or any always-on Linux box at home, enable forwarding with the same three sysctl lines as in Step 2, and advertise your home network. Replace 192.168.50.0/24 with your own range; ip -br addr on the Pi shows it.

# as riad on the home Raspberry Pi
sudo tailscale up --advertise-routes=192.168.50.0/24 --hostname=home-pi

Approve the route the same way as the exit node: Machines, find the Pi with the Subnets badge, Edit, tick the route, save. Before we approved it, the laptop got no answer from the NAS at 192.168.50.10. After approval it did.

Phones, Windows and macOS pick up approved routes on their own. Linux clients need to be told once (subnet router docs):

# as riad on the laptop
sudo tailscale set --accept-routes
curl http://192.168.50.10/

# output we saw
hello from the NAS at home

The exit node and the subnet route work together. With ams-vps as exit node, the laptop browsed from the Amsterdam address and still opened the NAS page at home. A Pi at home can also be an exit node, for the odd service that only trusts your home line.

Step 5: Tailscale SSH and MagicDNS

MagicDNS gives every device a name, so you type ams-vps instead of 100.64.0.1. It is on by default for tailnets created since October 2022, and full names end in your tailnet's .ts.net domain (MagicDNS docs). On our laptop, getent hosts ams-vps returned 100.64.0.1 at once.

Because the VPS was started with --ssh, Tailscale itself answers SSH on port 22 of the tailnet address and checks your tailnet login against the access policy, so there are no keys to copy. Your normal sshd configuration is left alone (Tailscale SSH docs).

# as riad on the laptop
ssh riad@ams-vps "hostname; whoami"

# output we saw
wf-ts-vps
riad

Our test VPS had no OpenSSH server installed at all, and the login still worked. Once Tailscale SSH works for you, you can close port 22 on the public interface and hide SSH from the bots that scan the internet all day. Test a Tailscale SSH login from a second terminal before you close anything.

The hosted service's default policy uses "check" mode for SSH, which asks you to re-confirm your login in the browser every 12 hours.

A small access policy you can paste

A fresh tailnet lets every device reach every other device. Once family or a colleague joins, write down who may reach what. Tailscale's policy file is HuJSON (JSON that allows comments and trailing commas), and the newer "grants" syntax describes access as source, destination, what (grants docs). Note that approving an exit node or a subnet route does not give anyone access to it; the policy has to allow it.

// policy file: paste into Access controls in the admin console (we tested it in Headscale)
{
  "grants": [
    // my devices may reach each other on any port
    {"src": ["autogroup:member"], "dst": ["autogroup:member"], "ip": ["*"]},
    // my devices may use exit nodes
    {"src": ["autogroup:member"], "dst": ["autogroup:internet"], "ip": ["*"]},
    // my devices may reach the home LAN behind the subnet router
    {"src": ["autogroup:member"], "dst": ["192.168.50.0/24"], "ip": ["*"]},
  ],
  // Tailscale SSH: log in to my own machines as a normal user
  "ssh": [
    {"action": "accept", "src": ["autogroup:member"], "dst": ["autogroup:self"], "users": ["autogroup:nonroot"]},
  ],
}

The last rule is the interesting one: SSH is allowed only as a non-root user. We tested it, and a root login was refused with:

# output we saw
tailscale: tailnet policy does not permit you to SSH as user "root"

Change "accept" to "check" on the hosted service if you want the periodic browser confirmation.

Turn off key expiry for the server

Every device's login key expires after 180 days by default. On a VPS that means your exit node and SSH access vanish on day 181, probably while you are travelling. Open Machines, click the menu next to the VPS and choose Disable key expiry (key expiry docs).

The cleaner way for servers is a tag such as tag:server: tagged devices belong to the tailnet, not to a person, and their key expiry is off by default. An auth key from the admin console joins a server without a browser, with sudo tailscale up --auth-key=... (auth key docs).

What it uses on the server

These numbers come from our lab, with Tailscale 1.104.1 on Debian 13 containers limited to 2 shared vCPUs each:

The throughput test ran between two containers on one host while other labs were busy, so read it as "the CPU is not the bottleneck", not as an internet speed. Your hotel Wi-Fi sets the limit long before the VPS does.

So the smallest plan is enough. A VPS Nano (1 vCPU, 1 GB RAM, 20 GB NVMe, 1 Gb/s) handles an exit node for one person or a family; the VPS Micro (2 vCPU, 2 GB) leaves room to also run something like Uptime Kuma or a Nextcloud that you only expose on the tailnet. Traffic on all our plans is unmetered. Every server gets its own IPv4 and IPv6, and servers in Amsterdam and Dublin get their own /48 of IPv6. In our lab the exit node advertised both 0.0.0.0/0 (IPv4) and ::/0 (IPv6), so it can carry IPv6 traffic as well when the VPS has IPv6.

Traffic leaving the exit node carries your server's address, so our acceptable use policy applies to it like any other traffic from the VPS.

Want no third party at all? Headscale

Headscale is an open-source reimplementation of Tailscale's coordination server under the BSD-3-Clause licence. It runs one tailnet, the official Tailscale apps connect to it, and it supports exit nodes, subnet routers, MagicDNS, Tailscale SSH and the policy file above (Headscale features). It is not affiliated with Tailscale Inc. The client commands are the ones in this guide plus --login-server https://your-headscale-address, and approvals happen on the command line instead of the admin console. In our lab these two did the job of the two clicks:

# as root on the Headscale server
headscale nodes approve-routes --identifier 1 --routes 0.0.0.0/0
headscale nodes approve-routes --identifier 2 --routes 192.168.50.0/24

The catch is that you now run the server everyone depends on, including TLS for its address (our reverse proxy guide covers certificates). For a VPN to one server without the mesh, plain WireGuard on a VPS needs no coordination server at all.

When it does not work

• The exit node is not in the menu: it was never approved under Edit route settings, or your policy has no grant to autogroup:internet.
• Websites do not load once the exit node is on: IP forwarding is off. Run sysctl net.ipv4.ip_forward on the VPS; it must print 1.
• tailscale status shows relay instead of direct: both sides are behind strict NAT or a firewall. Tailscale needs no inbound ports, but the firewall docs say allowing UDP 41641 inbound on the VPS can make direct connections possible.
• A Linux laptop cannot reach the home LAN: it is missing --accept-routes, or the route is not approved.

Frequently asked questions

Is a Tailscale exit node free?

Yes. Tailscale's documentation says exit nodes are available on all plans, including the free Personal plan for up to 6 users. You only pay for the VPS that acts as the exit node.

Does a Tailscale exit node change my IP address?

Yes. Websites see the public IP address of the exit node, for example your VPS in Amsterdam or Dublin, instead of the address of the hotel Wi-Fi or mobile network you are on. You can check it with any "what is my IP" site before and after switching it on.

Can Tailscale see my traffic through an exit node?

Tailscale says decrypted traffic never passes through its servers and that it does not log exit node traffic unless you turn on network flow logs. The traffic is encrypted from your device to your VPS, and it leaves the VPS like any normal internet traffic from that server.

What is the difference between an exit node and a subnet router?

An exit node carries all your internet traffic and gives you its public IP. A subnet router only carries traffic for one private network, such as your home LAN 192.168.1.0/24, so you can reach devices there that cannot run Tailscale themselves.

How much RAM does Tailscale need on a VPS?

Very little. In our lab, tailscaled used about 36 MB of memory on an exit node and 32 MB on a subnet router, so a 1 GB VPS is plenty for a personal exit node.

Why did my Tailscale server disconnect after 180 days?

Device keys expire after 180 days by default. Disable key expiry for the server on the Machines page of the admin console, or join servers with a tag, because tagged devices have key expiry turned off by default.

Set it up tonight

One small VPS, one Pi at home and ten minutes of commands give you a fixed European IP wherever you are, your home LAN without open ports, and SSH without keys. Pick a VPS in Amsterdam, Dublin or Prishtina on the plans page, and if you have a question about which city fits your case, ask us on Telegram.

← All articles