Connect Your Home Network from Anywhere in the World with Raspberry Pi

The classic way to reach your home network from a hotel room is to forward a port on the router, point a dynamic DNS name at it, and hope. That works. It also means an address that answers on the public internet, and public addresses get found — mass scanners sweep the entire IPv4 space continuously, and the first automated login attempt against a freshly opened SSH port typically arrives the same day. You are then in the business of running a hardened, patched, internet-facing service, permanently, as a hobby.

Tailscale removes the exposure rather than defending it. It is a coordination layer on top of WireGuard — a small, well-reviewed protocol with a fraction of OpenVPN’s code — that builds an encrypted peer-to-peer mesh, a “tailnet”, between devices you have authenticated. Nothing listens on your public IP. Your router’s inbound firewall stays entirely shut.

The honest cost: you are trading self-hosted independence for a dependency on a company’s control plane and on your identity provider. Tailscale cannot read your traffic — the WireGuard keys never leave your devices — but it does decide which devices are allowed into your tailnet, and if your Google or GitHub account is taken over, so is your network. That is a good trade for most people. It is not a trade everyone should make, and if it isn’t yours, self-hosted Headscale or plain WireGuard covers the same ground with more work.

This guide turns a Raspberry Pi into a gateway: first reachable itself, then advertising your whole home LAN, then optionally carrying all your internet traffic.

Copy All Commands from this Gist

Which Raspberry Pi Should You Use?

Any Pi will run the daemon. The constraint is throughput, and specifically where the bottleneck sits: WireGuard encryption is CPU work, and on older boards the network interface is hung off the USB bus rather than wired to the SoC.

Raspberry Pi 5 / 4 (recommended): Proper gigabit Ethernet and enough CPU to saturate a typical home upload link several times over. If the Pi is going to be an exit node carrying every device’s traffic, start here.
Raspberry Pi 3 Model B+ / B: Fine for SSH, admin access and moderate web traffic. Its Ethernet shares the USB 2.0 bus, so real-world throughput caps well below gigabit and falls further once encryption is in the path. Perfectly good if you already own one.
Raspberry Pi Zero 2 W / Zero W: Wi-Fi only, which adds latency you cannot tune away and throughput that varies with whatever else is on the 2.4 GHz band. Acceptable for reaching a couple of devices; a poor foundation for an always-on gateway you will be annoyed at from a hotel.

Whichever board you use, the component that will actually fail is the microSD card. A gateway writes logs continuously, and cheap cards die from it — usually by going read-only, so the Pi appears to be running while nothing it does persists. Boot from a USB SSD if you can, and if you can’t, buy an endurance-rated card and take a periodic image.

Why Tailscale Makes Sense from a Security Standpoint

Four properties do the real work here. Each is worth understanding before you rely on it, including where it stops:

Nothing listens on your public IP. Both peers make outbound connections and use NAT traversal to meet in the middle, so the router’s inbound firewall never opens. When traversal fails — symmetric NAT, CGNAT on a mobile carrier, a corporate guest network — the connection falls back to relaying through Tailscale’s DERP servers. It still works and it is still encrypted end-to-end, but latency rises noticeably and throughput drops. tailscale status tells you which mode you are in; if it says relay, that is why the file copy is slow.
End-to-end encryption via WireGuard. Keys are generated on each device and the private half never leaves it. The control plane distributes public keys and coordinates connections; it cannot decrypt your traffic. What it can do is add a new key to your tailnet — which is the specific risk Tailnet Lock exists to close.
Identity-based authentication. Devices enrol by authenticating to your existing identity provider, so your whole network’s security now rests on that account. This is a genuine improvement over a shared pre-shared key and a genuine concentration of risk. Put a hardware security key on that account and treat it as infrastructure, not as a login.
Access control lists. ACLs let you say that the laptop may reach the NAS on port 445 and nothing else may reach anything. The default policy for a personal tailnet is permissive — every device can talk to every other device — so this is a control you have to go and switch on. If you skip it, a compromised phone reaches everything the gateway advertises.

Step 1: Install Tailscale on the Raspberry Pi

Start by making sure your Raspberry Pi is fully up to date. Connect via a local SSH session or directly, then run:

sudo apt-get update && sudo apt-get upgrade -y

Next, the install script. It detects the distribution (Raspberry Pi OS is Debian-based), adds Tailscale’s signed apt repository, and installs from it — which matters, because it means future updates arrive through apt like everything else rather than needing you to re-run a script. Piping a remote script into a shell is still executing code you have not read; if that bothers you, fetch it to a file, read it, then run it:

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

Once the installation finishes, bring Tailscale up:

sudo tailscale up

The terminal prints a login URL. Open it in a browser, authenticate, and authorise the Pi to join your tailnet. Note what just happened: that URL is a bearer credential for enrolling a device. Don’t paste it into a chat window to open on your phone.

One default to change now rather than in three months. Machine keys expire — 180 days by default — and when the key on an unattended gateway expires, the Pi silently drops off the tailnet and you discover it from another country. For this one device, disable key expiry in the admin console. That is a deliberate weakening of a good control, justified only because the device is a fixed, physically controlled box; do not do it for laptops or phones.

Step 2: Verify the Connection

Your Pi now holds a stable address in 100.64.0.0/10, the range reserved for carrier-grade NAT — chosen precisely because it will not collide with the 192.168.x.x or 10.x.x.x space of any network you visit. It survives reboots and is unaffected by your home IP changing, which is the entire dynamic DNS problem solved by not having the problem.

To find your Pi’s Tailscale IP:

tailscale ip -4

From any other device on your tailnet (with Tailscale installed), you can now SSH in securely:

ssh pi@<your-tailscale-ip>

If you’re running a newer version of Raspberry Pi OS, the default pi user no longer exists by default — substitute whatever username you configured during setup.

Make sure Tailscale starts automatically on boot:

sudo systemctl enable --now tailscaled

You can verify it comes back up correctly with a quick reboot:

sudo reboot

Step 3: Turn the Pi into a Subnet Router

So far you can reach the Pi. A subnet router advertises your entire home LAN across the tailnet, so you can reach the NAS, the hypervisor’s management interface, the smart home hub and the printer — none of which will ever run a Tailscale client.

Be clear about what this changes. Up to now, compromising a tailnet device got an attacker one Raspberry Pi. After this, it gets them a route onto your whole home network, including every device on it that has no authentication because “it’s only on the LAN”. This is the step where ACLs stop being optional.

Enable IP Forwarding

The Linux kernel needs IP forwarding turned on to route traffic between interfaces. Create a dedicated sysctl configuration file for this:

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

Find Your Local Subnet

Check your active network interface to identify your home subnet:

ip -4 addr show

You’re looking for a range like 192.168.1.0/24 or 10.0.0.0/24 on eth0 or wlan0. Two things to check before you advertise it. First, that the subnet is what your router actually hands out and not just the slice your Pi sits in. Second — and this bites people constantly — that the network you will be connecting from does not use the same range. Half the routers sold default to 192.168.1.0/24, and a coffee shop using the same subnet as your home gives you an ambiguous route and traffic that goes nowhere useful. If you have the option, renumber your home LAN to something unlikely, such as 192.168.87.0/24.

Advertise the Route

Tell Tailscale to make your home subnet accessible across your tailnet. Replace the IP range below with your actual subnet:

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

Approve the Route in the Admin Console

Advertising a route does nothing until an administrator approves it. That gate exists because any node in a tailnet can claim to route any subnet, including one it has no business routing, and route hijacking is otherwise trivial. It is also the reason your subnet routing “isn’t working” ninety per cent of the time: the command ran fine, the approval never happened.

Log in to the Tailscale Admin Console.
Find your Raspberry Pi in the machine list.
Click the three dots (…) next to it and select Edit route settings.
Under Subnet routes, check the box for your subnet and click Save.

Tailscale applies Source NAT automatically, so traffic arrives at your NAS appearing to come from the Pi rather than from a 100.64.x.x address the NAS has no route back to. No manual iptables masquerading required. The side effect is worth knowing: every device on the LAN sees one source IP for all remote access, so LAN-side logs cannot tell your laptop from your phone. Turn SNAT off (--snat-subnet-routes=false) only if you are prepared to add return routes on the LAN side.

Step 4: Set Up an Exit Node

A subnet router gets you to your home network. An exit node sends all of your device’s internet traffic through the Pi and out of your home connection — the closest thing here to what people mean when they say “VPN”.

Two caveats before you enable it. Your ceiling is your home upload speed, which on most consumer connections is a small fraction of the download figure on the bill, and every byte crosses it twice; expect this to feel slow. And the threat model is narrower than it sounds. Public Wi-Fi eavesdropping is a much smaller problem than it was a decade ago, now that essentially all traffic is TLS-protected. What an exit node genuinely buys you is that the café network sees only encrypted WireGuard to one endpoint — no DNS queries, no SNI, no destination addresses — plus a stable home IP for services that geo-restrict or allowlist. That is a real benefit, and it is not the same as “otherwise you’d be hacked”.

Advertise the Exit Node

Run this on the Raspberry Pi:

sudo tailscale up --advertise-exit-node

If you want the Pi to act as both a subnet router and an exit node at the same time, combine the flags:

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

Approve It in the Admin Console

Open the Tailscale Admin Console.
Locate your Raspberry Pi, click the three dots (…), and select Edit route settings.
Under Exit node, check the authorisation box and click Save.

Step 5: Harden the Setup

The Pi is now the single device that can reach everything you own. Its compromise is your network’s compromise, so it deserves more care than the average project board.

Use Tailscale SSH

Tailscale SSH moves authentication from keys you manage to identity and ACLs the tailnet enforces, and it means port 22 is never exposed anywhere. The upside is central revocation: removing someone’s access removes their SSH access at the same instant, rather than after you remember to edit authorized_keys.

The trade-off is that your SSH access now depends on the Tailscale control plane being reachable. Keep a conventional key-based path available on the LAN as a fallback, or keep a keyboard and monitor nearby, because the day you need to get into this box is the day something else is broken too.

Enable it by restarting Tailscale with the --ssh flag:

sudo tailscale up --ssh

Once enabled, you can SSH into your Pi from any authorised tailnet device without touching key configuration.

Configure UFW

UFW’s default forward policy is deny, which does not stop the Pi talking to your tailnet but does silently drop everything you are trying to route through it. Direct access to the Pi keeps working, so the symptom is “Tailscale is up but I can’t reach the NAS” — and the packets are being discarded with no log entry unless you turn logging on.

Allow the UDP port Tailscale prefers for direct connections:

sudo ufw allow 41641/udp

Allow forwarding between the Tailscale interface and your LAN interface. Substitute your actual interface name if it isn’t eth0 — on a Wi-Fi-connected Pi it will be wlan0, and the rules below will silently do nothing if you get it wrong:

sudo ufw route allow in on tailscale0 out on eth0
sudo ufw route allow in on eth0 out on tailscale0

Allow inbound SSH specifically from your tailnet:

sudo ufw allow in on tailscale0 to any port 22 proto tcp

Apply the changes:

sudo ufw reload

Lock Down Your Tailscale Account

Everything above protects the Pi. None of it helps if someone takes over the account that decides which devices belong to your tailnet, so spend ten minutes here:

MFA on your identity provider. This is the actual perimeter now. Hardware security keys (FIDO2/WebAuthn) are the only second factor that resists phishing outright — an SMS code or an app prompt can be relayed by a convincing login page, a security key cannot, because it checks the origin for you. Register two and keep one somewhere else.
Tailnet Lock. Signs node keys with keys you hold, so a compromised control plane still cannot add a device to your network. It is the strongest control here and the one with the sharpest edge: lose your signing keys and you cannot enrol anything new. Set it up with more than one trusted signer before you rely on it.
Key expiry. Short expiry limits how long a lost laptop stays authorised. Apply it to portable devices, and — as noted earlier — deliberately exempt the gateway, whose unattended key expiry is otherwise the classic way to lock yourself out of your own house from abroad.
ACLs. Write a policy that matches how you actually use the network: laptop reaches the LAN, phone reaches the Pi and nothing else. The default “everything talks to everything” is convenient and is exactly what lateral movement looks like when it goes wrong.
Review the machine list occasionally. Old phones and rebuilt laptops linger in tailnets for years. Anything you cannot identify should be removed rather than left alone.

Troubleshooting

Check Connection Status

Start here. The output lists every peer and, crucially, how you are reaching it:

tailscale status

direct means a peer-to-peer connection; relay "…" means traffic is going via a DERP relay because NAT traversal failed. Both work. Only one is fast, so read this before blaming the Pi for slow transfers.

To test a specific peer and see which path it takes:

tailscale ping <client-tailscale-ip>

This often reports a relayed path for the first few packets and then switches to direct as traversal completes — that is normal, and worth waiting for before concluding anything.

Check IP Forwarding

If subnet routing or exit node traffic isn’t passing, confirm forwarding is active now rather than merely configured. A sysctl.d file that was never applied, or was applied before a reboot that reset it, produces a working Pi and a route that quietly drops everything:

cat /proc/sys/net/ipv4/ip_forward

1 means it’s on. 0 means every packet you are trying to route is being dropped by the kernel, silently and without an error anywhere — revisit the sysctl step. If forwarding is on and traffic still doesn’t pass, the next suspect is UFW’s forward policy.

Inspect the Logs

For unexplained daemon behaviour:

sudo journalctl -u tailscaled -n 50 --no-pager

Restart or Re-authenticate

A restart clears most transient state problems, and does so without disturbing your node’s identity:

sudo systemctl restart tailscaled

To force full re-authentication — the fix when a key has expired or the node has been removed from the tailnet:

sudo tailscale down
sudo tailscale up --force-reauth

Remember that this needs an interactive browser login, so it is the one recovery step you cannot complete remotely if the Pi is your only way in. Confirm you have another route to the box before running it.

Connecting Your Other Devices

With your Raspberry Pi configured, all you need is the Tailscale client on your other devices.

Windows / macOS: Download the installer from tailscale.com/download, run it, and sign in with the same account.
Linux: Run curl -fsSL https://tailscale.com/install.sh | sh, then sudo tailscale up.
Android / iOS: Install Tailscale from the Google Play Store or Apple App Store, authenticate, and flip the toggle to connect.

Using the Exit Node

Once your device is connected to the tailnet, switching internet traffic through the Raspberry Pi takes just a few taps:

Mobile apps: Open Tailscale, tap the exit node selector, and choose your Raspberry Pi.
Desktop (Windows / macOS): Click the Tailscale icon in the system tray or menu bar, go to Exit Nodes, and select the Pi.
Linux CLI: Run sudo tailscale set --exit-node=<your-pi-tailscale-ip>.

From that point your traffic leaves the internet from your home connection rather than the hotel’s. Expect the speed drop, remember that it is bounded by your home upload, and turn it off when you don’t need it — an exit node left permanently enabled is the fastest way to convince yourself the whole setup is too slow to use.

Two things worth doing once everything works: turn on ACLs while the network is still small enough to reason about, and write down — on paper, not on the NAS — how you would get back in if the Pi were unreachable. Remote access you cannot recover is just a slower kind of lockout.