How to Configure a Tailscale Exit Node (September 2026)?

A Tailscale exit node is a device on your tailnet that routes 100% of your internet traffic through its connection, so any device you connect from appears to be on the exit node’s network. In this guide, I’ll walk you through how to configure a Tailscale exit node for full-tunnel VPN access, from choosing the right platform to approving it in the admin console and connecting from client devices.

I’ve personally run exit nodes on a Hetzner VPS, a Synology NAS, and a Raspberry Pi 4, and I’ll share the exact CLI commands, the gotchas that broke my setup the first time, and the troubleshooting steps that actually fix things. By the end of this guide, you will have a working exit node that protects you on coffee shop WiFi, gives you a home-country IP when traveling, and gives you full visibility into every packet leaving your devices.

What Is a Tailscale Exit Node?

A Tailscale exit node is a Tailscale-connected machine that advertises itself as an internet gateway for the rest of your tailnet. When another device routes through it, all traffic exits the internet using the exit node’s public IP address instead of its own.

Think of it as a self-hosted VPN server you fully control, but built on top of WireGuard instead of OpenVPN or IPSec. Tailscale handles the key exchange, NAT traversal, and DERP relay fallback so you do not need to forward ports or open firewall rules to make it work.

The traffic flow looks like this:

• Your laptop or phone opens a WireGuard tunnel to a Tailscale coordination server and discovers the exit node.

• All outbound packets are encapsulated inside WireGuard and sent to the exit node over a direct peer-to-peer connection (or via a DERP relay if direct connection fails).

• The exit node decapsulates the packets and forwards them to the public internet using its own routing table, so the destination sees only the exit node’s IP.

• Return traffic flows back the same path.

One thing that surprises people: Tailscale itself runs the control plane, but the data plane is direct between your devices. Your traffic does not pass through Tailscale’s servers. They only see metadata such as connection timestamps, peer IDs, and DERP relay usage, not the contents of your packets.

When Should You Use a Tailscale Exit Node?

A Tailscale exit node makes sense when you need your traffic to appear to come from somewhere else, or when you want to enforce a single chokepoint for visibility and security. Here are the four scenarios where I reach for one.

• Public WiFi protection: Hotel, airport, and coffee shop networks are full of packet sniffers and captive portals. Routing through an exit node on a trusted network encrypts everything between you and the exit node.

• Travel and home-country access: When I’m overseas, an exit node in my home country lets me bank, stream, and access services that are geofenced.

• Homelab gateway: Pairing an exit node with a subnet router gives you both internet routing and access to your home LAN devices from anywhere.

• Visibility and logging: Because every packet exits through one machine, you can run tcpdump, journald logs, or network flow logs in one place. For teams, this means real destination logging instead of guessing.

If you only need to reach a few specific services behind your home network, a subnet router alone is enough. Save the exit node for when you actually want full-tunnel VPN behavior.

Prerequisites for Configuring an Exit Node

Before you start configuring your Tailscale exit node, gather these four things. Skipping any of them leads to the “why is my exit node not working” posts I see weekly on Reddit.

• A Tailscale account: Sign up at tailscale.com. The free Personal plan supports exit nodes and is enough for most users. Business plans add ACL-driven approval.

• A device to act as the exit node: Anything running Linux, macOS, Windows, or a supported NAS OS. A VPS works best for travel use, while a Raspberry Pi or home server works for local-network protection.

• Public IPv4 (or IPv6) connectivity: The exit node must be reachable on the internet. Most cloud VPS providers give you this by default.

• Ability to run sudo or root: IP forwarding requires kernel parameters that need elevated privileges.

For most people, the cheapest option is a Hetzner CX11, Vultr, or DigitalOcean droplet. Community benchmarks on Reddit show 18-25ms latency from Europe to a Frankfurt VPS, and VPNSmith measured 680 Mbps throughput on a small cloud server, which is more than enough for everyday browsing and 4K streaming.

How to Configure a Tailscale Exit Node (Step-by-Step)?

I’ll show you the exact steps using Ubuntu 24.04 LTS as the exit node, since that’s what most cloud VPSes ship with. The Linux commands also work on Debian, Fedora, and Raspberry Pi OS with minor package-manager differences.

Step 1: Install Tailscale on the Exit Node

SSH into the machine that will be your exit node, then run the official install script:

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

This installs the tailscaled daemon and the tailscale CLI. Next, bring the interface up and authenticate:

sudo tailscale up

A login URL appears in your terminal. Open it, sign in with your account, and the device joins your tailnet with its default name. You can rename it later in the admin console if you want something friendlier like exit-node-frankfurt.

Step 2: Enable IP Forwarding

This is the step most beginners miss, and it’s the number one reason a Tailscale exit node silently fails to route traffic. By default, Linux drops packets that arrive on one interface and need to leave on another, which is exactly what an exit node does.

Enable forwarding temporarily:

sudo sysctl -w net.ipv4.ip_forward=1
sudo sysctl -w net.ipv6.conf.all.forwarding=1

Make it survive reboots by editing /etc/sysctl.d/99-tailscale.conf:

net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1

Then apply it:

sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

If you’re using nftables, iptables, or ufw, make sure the FORWARD chain allows traffic from the Tailscale interface (tailscale0) to your outbound interface (often eth0). On most cloud VPS images the default policy allows forwarding, but on Ubuntu with ufw you’ll need:

sudo ufw route allow in-interface tailscale0 out-interface eth0
sudo ufw route allow in-interface eth0 out-interface tailscale0

Step 3: Advertise the Exit Node

Now tell Tailscale that this device is willing to be an exit node:

sudo tailscale up --advertise-exit-node

To also let other devices reach your home LAN through this same machine, add the subnet router flag:

sudo tailscale up --advertise-exit-node --advertise-routes=192.168.1.0/24

Replace 192.168.1.0/24 with your actual subnet. After running this, check the status:

tailscale status

You should see a line that says something like offers exit node next to your device.

Step 4: Approve the Exit Node in the Admin Console

By default, a freshly advertised exit node is not yet allowed to be used. You need to approve it once:

1. Open the Tailscale admin console at login.tailscale.com/admin.

2. Click the device name of your exit node.

3. Find the “Edit route settings” section near the bottom of the page.

4. Toggle “Use as exit node” to enabled and click Save.

If you also advertised a subnet route, approve that on the same screen. Until this approval is done, your clients will see “no exit nodes available” even though the device is online.

Step 5: Configure Access Controls (ACLs)

If you’re on a Personal plan, any device in your tailnet can use any approved exit node. On a Business or Enterprise plan, you control this through ACLs. The minimum ACL for allowing a user to use an exit node is:

{ "acls": [ { "action": "accept", "src": ["autogroup:members"], "dst": ["autogroup:internet"] } ] }

You can also restrict exit nodes to specific users or tags. For example, to let only the “ops” group use the Frankfurt exit node:

{ "acls": [ { "action": "accept", "src": ["group:ops"], "dst": ["tag:exit-frankfurt:*"] } ] }

Tag your exit node with sudo tailscale up --advertise-exit-node --tags=tag:exit-frankfurt to make this work.

How to Approve and Use the Exit Node from a Client Device?

Once the exit node is approved, picking it up on a client is a one-line command or a single click in the GUI. Here’s how to do it on each platform.

macOS and Windows

Open the Tailscale app from the menu bar or system tray. Click “Use exit node” and select your approved machine from the dropdown. To disable, click the same menu and choose “None.”

Or from the terminal:

tailscale set --exit-node=exit-node-frankfurt

To clear it:

tailscale set --exit-node=

iOS and Android

On mobile, open the Tailscale app, tap the connection switch to expand options, then choose “Exit Node” and pick from the list. iOS picks up the exit node instantly. Android has a known limitation: the official client uses userspace WireGuard, which means throughput is lower and a few advanced routing features do not work as smoothly as on Linux.

Linux CLI

Use the same tailscale set --exit-node=<name> command. To see all available exit nodes:

tailscale exit-node list

The output lists every approved exit node with its name, IP, and country. Pick one and you’re routed through it within a second.

Verifying the Exit Node Is Active

Before you trust the connection, confirm it actually changed your public IP. The fastest way:

curl https://ifconfig.me

If the IP returned matches your VPS’s public IP, the exit node is working. You can also check:

tailscale status

Look for the line that says you are using an exit node and which one. If the line is missing, you forgot the approval step or your ACL is blocking it.

Exit Node vs Subnet Router: What’s the Difference?

Both features advertise routes from a single device, but they do different things. Understanding the difference saves you hours of confused debugging.

• Subnet router: Advertises a private IP range (like 192.168.1.0/24) so other tailnet devices can reach machines on that LAN. It does not change your public IP or route internet traffic.

• Exit node: Advertises itself as the default route (0.0.0.0/0) so all internet-bound traffic from clients flows through it.

A single device can do both at once. That’s why the install command earlier used --advertise-exit-node --advertise-routes=192.168.1.0/24. You get LAN access for file servers, plus internet routing, all from one box.

Choose a subnet router alone when you only need to reach specific services (a NAS, a printer, a home server). Choose an exit node when you need VPN-style protection or want all traffic to appear from one place. Choose both when you want the full homelab experience.

Troubleshooting Common Tailscale Exit Node Issues

Even when you follow every step, something eventually breaks. These are the issues I see most often, and the fixes that work.

Exit Node Not Approved

Symptom: The device shows up in your tailnet but does not appear in the client’s exit node dropdown. Cause: you skipped Step 4 above. Fix: open the admin console, find the device, and toggle “Use as exit node” on.

Traffic Not Routing Through the Exit Node

Symptom: You picked an exit node but curl ifconfig.me still shows your local IP. Causes: IP forwarding is off, firewall is blocking the FORWARD chain, or ACLs deny the user. Fix: re-check the net.ipv4.ip_forward sysctl and run sudo iptables -L FORWARD to confirm the chain allows traffic.

DNS Leaks After Enabling

Symptom: Even with the exit node active, dnsleaktest.com shows resolvers in your physical location. Cause: Tailscale’s MagicDNS is being bypassed by apps that hardcode their own DNS (some smart TVs and games do this). Fix: enable “Override local DNS” in the Tailscale client settings so all DNS queries go through MagicDNS or your exit node’s resolver.

Key Expiry Causing Failure

Symptom: The exit node works for weeks, then suddenly stops. Cause: Tailscale keys expire (default 180 days for tagged devices, sometimes shorter for auth keys). Fix: either disable key expiry on the exit node with sudo tailscale up --advertise-exit-node --authkey=tskey-auth-xxxx using a pre-authenticated key, or set up an automation to renew.

Firewall Blocking WireGuard

Symptom: Direct peer-to-peer connection fails and Tailscale falls back to DERP relay, which is much slower. Cause: UDP port 41641 is blocked. Fix: open the port or rely on DERP. Tailscale detects blocked ports automatically and degrades gracefully, but latency rises from 20ms to 150ms+.

For deeper issues, tailscale debug and tailscale netcheck dump diagnostic info that explains most connection problems in one screen.

Security and Privacy Considerations

An exit node is a powerful tool, and with power comes responsibility. Here is what to think about before you start routing production traffic through one.

What Tailscale can and cannot see: Tailscale runs the control plane, so it knows your device list, peer connections, and DERP relay usage. It does not see packet contents because the data plane is direct peer-to-peer over WireGuard. The exit node itself can see every destination you visit unless you add another layer like an HTTPS-only browser setup.

Combining exit node with other VPNs: Running a Tailscale exit node inside an existing OpenVPN or WireGuard tunnel works, but adds latency and complexity. Most users pick one. If you need both, run Tailscale on the inner layer so DNS stays simple.

Restrictive networks and DPI: WireGuard traffic can be fingerprinted by deep packet inspection. Users in heavily censored regions (some have reported issues from Russia) report that Tailscale blocks outright. If you need censorship resistance, look at obfuscation tools like V2Ray or use Tailscale over an SSH tunnel.

Auth key handling: If you use pre-authentication keys for unattended exit nodes (a Raspberry Pi at home, for example), treat them like passwords. Rotate them, scope them to specific tags, and never commit them to a public repo.

Performance Tips for Your Tailscale Exit Node

Out of the box, a Tailscale exit node on a small VPS handles 4K streaming and video calls without breaking a sweat. If you need more, here are the levers I pull.

• Pick a nearby region: Latency is dominated by physics. A Frankfurt exit node gives 18-25ms from most of Europe, but 200ms+ from Singapore. Pick the closest region you can afford.

• Tune MTU: Tailscale defaults to 1280 MTU for safety. On a VPS with no encapsulation overhead, raising it to 1420 often improves throughput by 10-15%.

• Enable BBR congestion control: On Linux 4.9+, sudo sysctl net.ipv4.tcp_congestion_control=bbr lets the kernel handle packet loss better than CUBIC. Combined with Tailscale, throughput on a 1 Gbps VPS climbs from ~680 Mbps to ~900 Mbps in benchmarks.

• Watch DERP relay usage: If tailscale netcheck shows you’re bouncing through DERP, your exit node is not running with full capabilities. Direct connections are always faster.

If you hit 1 Gbps and want more, the bottleneck is usually the VPS’s outbound bandwidth cap, not Tailscale itself.

Frequently Asked Questions

Conclusion

Configuring a Tailscale exit node for full-tunnel VPN access takes about 20 minutes once you know the order: install Tailscale, enable IP forwarding, advertise the exit node, and approve it in the admin console. After that, every client in your tailnet can route all traffic through it with one click.

Start with a small cloud VPS in your home region, run the steps above, and verify with curl ifconfig.me. Once you trust the setup, you can layer on subnet routing for LAN access, ACLs for team control, and BBR for extra throughput. A working Tailscale exit node gives you full-tunnel VPN protection without monthly fees, port forwarding, or trust in a third-party VPN provider.