What Tailscale Exit Nodes Actually Do
Most VPN setups require a subscription, a commercial server somewhere overseas, and a fair amount of trust in whoever runs it. Tailscale exit nodes offer a different model: route your internet traffic through a machine you already own and control, whether that’s a home server, a Raspberry Pi, or a cloud VM, using WireGuard encryption underneath and a configuration process that takes minutes instead of hours.
Setting Up Your Exit Node
Before anything else, you need a Tailscale account and the Tailscale client installed on at least two machines: the one you want to designate as the exit node, and the device you’ll be routing traffic from. Tailscale supports Linux, Windows, macOS, iOS, and Android, so the combination is flexible. The exit node itself is most commonly a Linux machine – a home server, a NAS running a compatible OS, or a cheap VPS – because Linux gives you the most control over IP forwarding settings.
On the machine that will act as the exit node, you need to enable IP forwarding at the operating system level. On Linux, this means editing /etc/sysctl.conf and setting net.ipv4.ip_forward=1 and net.ipv6.conf.all.forwarding=1, then applying the changes with sysctl -p. Without this step, the machine will accept the Tailscale configuration but silently fail to forward traffic, which produces one of the more frustrating debugging scenarios in home networking.
Once IP forwarding is active, advertise the exit node by running: tailscale up –advertise-exit-node. This flags the machine in your Tailscale admin console as an available exit node, but it does not activate it yet. You still need to approve it from the admin panel at login.tailscale.com, under the Machines tab. Find your device, open its settings, and enable “Use as exit node.” Tailscale requires this manual approval step deliberately – it prevents a compromised device from silently redirecting traffic without account-level confirmation.
If you’re running a firewall on the exit node (and you should be), make sure you allow traffic on UDP port 41641, which Tailscale uses for direct peer-to-peer connections. Some NAT configurations will fall back to DERP relay servers if direct connections can’t be established, which still works but adds latency. Opening that port in your firewall and configuring port forwarding on your router if needed keeps connections direct and fast. On UFW-based systems, sudo ufw allow 41641/udp is the relevant command.
Connecting Devices Through the Exit Node
With the exit node approved and running, connecting a client device is straightforward. On Linux, run tailscale up –exit-node= followed by the IP address or Tailscale hostname of your exit node machine. On Windows and macOS, open the Tailscale system tray menu, navigate to “Exit Node,” and select your machine from the list. On iOS and Android, the same option appears inside the Tailscale app under the connection settings. All traffic from that device – DNS queries, HTTP requests, everything – now routes through your exit node before reaching the open internet.
DNS behavior deserves attention here. By default, Tailscale uses its own MagicDNS system, which handles name resolution within your tailnet. When you enable an exit node, you can also tell Tailscale to route DNS through that node by checking “Allow LAN access” or configuring a custom DNS server in the admin console. If you leave DNS handling to the default settings, your DNS queries may still go through Tailscale’s resolvers rather than your home network’s resolver, which matters if you’re running something like Pi-hole locally and want its filtering to apply to exit node traffic.
The “Allow LAN access” toggle is worth understanding separately. When enabled on a client device using an exit node, it lets that device continue reaching local network resources – printers, NAS devices, local services – without routing that traffic through the exit node. When disabled, all traffic including LAN-bound requests goes through the exit node first. For most remote access use cases, keeping LAN access enabled on the client makes sense; for maximum privacy routing where you want no local traffic leaking, disable it.
One practical consideration: the machine running the exit node will see all outbound internet traffic from connected clients, which means your home IP address or VPS IP address becomes the apparent origin of that traffic. This is exactly the point for many users – substituting a trusted IP for whatever public WiFi network you’ve connected to – but it also means the exit node machine’s internet connection becomes a bottleneck. A Raspberry Pi 4 on a 100 Mbps connection will cap your throughput at that rate regardless of how fast the client device’s own connection is.
Multiple exit nodes are entirely possible within a single Tailscale network. You can have a home server for general use, a cloud VPS in a specific region for geo-specific access, and a travel router configured as a mobile exit node, all available from the same Tailscale admin panel and switchable from any client device with a few taps. Tailscale’s free tier supports up to 100 devices and 3 users, which covers most personal and small-team setups without any cost.
Hardening and Ongoing Management
Running your own exit node means you’re responsible for keeping it secure. That starts with keeping the host OS patched, disabling password-based SSH in favor of key authentication, and reviewing the Tailscale ACL rules in your admin console. Tailscale’s access control lists let you restrict which devices on your tailnet can actually use the exit node, so if you share your tailnet with family members or colleagues, you’re not automatically giving everyone exit node access. A basic ACL rule targeting exit node usage by specific users or device tags takes about ten minutes to configure and significantly tightens the setup.
Tailscale logs connection events, and the admin console shows which devices are connected, when they last checked in, and what exit node they’re using – useful for spotting anything unexpected. If you’re running the exit node on a machine that also hosts other services, like a self-hosted NAS or app server, monitor resource usage to make sure exit node traffic isn’t competing with those workloads under heavy use. A dedicated low-power machine for exit node duties is worth considering if traffic volume grows.
