How to Set Up a Tailscale Exit Node on a VPS

A Tailscale exit node routes a tailnet device's ordinary internet traffic through a Linux VPS. Websites then see the VPS public IPv4 address, while the path between the client and exit node is encrypted. It is useful on untrusted Wi-Fi or when a team needs a stable egress location; it is not an anonymity service, content filter, or substitute for endpoint security.

This guide targets Ubuntu 24.04 LTS on x86-64, a recent Linux kernel, Tailscale's stable Linux packages, and kernel-mode forwarding. LayerOne gives the VPS a public IPv4 address, which improves the chance of a direct peer connection when UDP can reach it.

Tailscale exit-node requirements and LayerOne cost

The 10 Gbps port is a port cap, not a promised VPN result. Encryption, one-flow CPU performance, client access speed, route latency, direct versus relayed connections, and the remote site all affect throughput. A low-volume personal node can start on gc.nano; no.micro is the recommended shared exit-node SKU because it adds a second vCPU and the Network Optimized port.

LayerOne bills the VPS hourly from prepaid credit. Heavy exit-node traffic also uses the account's transfer pool; read Bandwidth. Taxes, extra transfer, optional services, and any paid Tailscale plan are not included in the server price. Confirm live values on Pricing.

1. Harden Ubuntu and decide who may use the node

Complete Your first hour on a new server. In the Tailscale admin console, decide which users or groups should be allowed to use exit nodes. Tailscale requires three separate choices: the VPS advertises the route, a tailnet administrator approves it, and each client opts into using it.

Do not put unrelated public services on this host. The exit node receives user traffic and should have a small, auditable attack surface.

2. Install Tailscale's stable Linux package

Tailscale publishes an installation script for mainstream Linux distributions. Download it first so it can be inspected rather than piping it directly into a root shell:

curl -fsSL https://tailscale.com/install.sh -o /tmp/install-tailscale.sh
less /tmp/install-tailscale.sh
sudo sh /tmp/install-tailscale.sh
sudo systemctl enable --now tailscaled
tailscale version

Authenticate the VPS to the correct tailnet:

sudo tailscale up

Open the one-time URL printed by the command and sign in. Use a tagged device or an appropriately scoped identity for an organization-managed tailnet.

3. Enable IPv4 and IPv6 forwarding

Tailscale requires IP forwarding on a Linux exit node. Store it in a dedicated sysctl file and apply it immediately:

sudo tee /etc/sysctl.d/99-tailscale.conf >/dev/null <<'EOF'
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1
EOF

sudo sysctl -p /etc/sysctl.d/99-tailscale.conf
sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding

Both values should print 1. LayerOne does not currently provide public IPv6, so do not promise IPv6 egress merely because forwarding is enabled.

4. Configure the firewalls for a direct tunnel

Most Tailscale nodes work without an inbound rule by falling back to NAT traversal or DERP relays. Allowing the daemon's default UDP 41641 listener on a public VPS improves the chance of a direct connection. Replace the administrator CIDR before enabling UFW:

ADMIN_CIDR="198.51.100.24/32"
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from "$ADMIN_CIDR" to any port 22 proto tcp
sudo ufw allow 41641/udp
sudo ufw enable
sudo ufw status verbose

In the LayerOne cloud firewall, use inbound DROP; allow TCP 22 only from the administrator CIDR and UDP 41641 from 0.0.0.0/0. Do not open a web UI, proxy, or arbitrary forwarded destination ports. Keep outbound ACCEPT: Tailscale needs outbound HTTPS for coordination and relays, UDP for direct tunnels, and STUN traffic.

When enabling IP forwarding, keep the firewall's general forwarding policy deny-by-default so the machine does not become an unintended generic router. Tailscale manages the rules needed for approved tailnet traffic.

5. Advertise and approve the exit node

Advertise the default routes, then run tailscale up as required by Tailscale's current Linux flow:

sudo tailscale set --advertise-exit-node
sudo tailscale up
tailscale status

In the Tailscale admin console, open Machines, find this VPS, and approve its exit-node routes. A tailnet grant or ACL must also permit the intended sources to reach autogroup:internet; do not grant the entire tailnet unless that is the actual policy.

On a test client, select this VPS as its exit node. On Linux the client command is:

sudo tailscale set --exit-node=EXIT_NODE_TAILSCALE_IP

Replace the placeholder with the VPS Tailscale IP from tailscale status.

6. Verify traffic uses the exit node

First capture the public IPv4 address on the VPS:

curl -4 https://ifconfig.co
tailscale netcheck
tailscale status

Run the same curl command on the connected client. The two public addresses should match. Then inspect the path:

tailscale ping EXIT_NODE_TAILSCALE_IP

A direct path is normally faster than a DERP-relayed path. Do not benchmark until tailscale ping identifies which one you are measuring. Test DNS, ordinary HTTPS, large downloads, and video calls from a representative client, then watch host usage:

sudo journalctl -u tailscaled -n 100 --no-pager
sudo ss -lunp | grep 41641
top -p "$(pidof tailscaled)"

7. Apply the documented Linux throughput optimization

Tailscale recommends UDP GRO forwarding for a Linux 6.2-or-newer exit node using Tailscale 1.54 or newer. Confirm the versions first, install ethtool, and apply the setting to the default-route interface:

uname -r
tailscale version
sudo apt install -y ethtool
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 'rx-udp-gro-forwarding|rx-gro-list'

The ethtool change does not survive a reboot by itself. Follow Tailscale's performance guide for the persistence method appropriate to the VPS network manager, and retest after a reboot rather than assuming it applied.

8. Upgrade, monitor, and remove safely

Keep Tailscale on its stable package track:

sudo apt update
sudo apt install --only-upgrade tailscale
tailscale version
tailscale status

Monitor transfer usage, direct-versus-relayed state, packet loss, CPU, and the Tailscale machine's key/approval status. A backup of /var/lib/tailscale/tailscaled.state contains the node identity and must be treated as a secret. Restore that state only with the original node offline; running two machines with one identity creates an unsafe and confusing failure mode. A clean replacement is often safer: authenticate the new VPS, approve it, switch clients, then remove the old machine in the admin console.

To stop a client using an exit node:

sudo tailscale set --exit-node=

Before destroying the VPS, remove its exit-node approval and machine entry so a stale identity cannot be mistaken for a healthy route.

Security and operational pitfalls

• Every site sees the LayerOne VPS public IP; activity can generate abuse complaints or consume substantial transfer.
• The exit node operator can observe destination metadata and unencrypted traffic. Continue to use HTTPS and end-to-end application encryption.
• A VPN does not make prohibited or unlawful traffic acceptable. Apply account, provider, and destination policies.
• Restrict autogroup:internet access to the intended users or devices.
• Keep SSH restricted and do not co-host a public control panel.
• Do not advertise unrelated subnet routes unless the VPS is meant to route them.
• Test a second exit node before depending on one VPS for emergency access.

Official references

• Install Tailscale on Linux
• Configure a Linux exit node
• Firewall ports used by Tailscale
• Tailscale performance best practices
• Tailscale CLI reference