When the team asks for the office NAS, a build-box shell and a safe way off hotel Wi-Fi, one Ubuntu server can do all of it. Install Tailscale on Ubuntu 26.04 and that server becomes a subnet router for the NAS, an exit node for the laptops and a Tailscale SSH target for the shell, so you don’t need port forwards or a separate VPN concentrator.
Each of those jobs fails quietly in its own way. Advertise a route without IP forwarding and peers get a route that leads nowhere, which is why recent clients now flag it as a health check. This update re-tests every step on Ubuntu 26.04 LTS against Tailscale 1.104.4, the stable release in November 2026, with a Headscale control server standing in for the hosted tailnet. Every output below comes from those three lab VMs; the tailscale.com login and console steps are taken from Tailscale’s docs and say so where they appear.
How the lab fits together
Three Ubuntu 26.04 VMs make up the test network. vpn-gw runs Tailscale and becomes the subnet router, exit node and SSH target. ops01 is the peer that uses all three. hs01 runs Headscale, the open source control server, because the lab had no tailscale.com account to log in with.
The control server only hands out keys, addresses and routes. Once both nodes know about each other, packets go straight from ops01 to vpn-gw over WireGuard on UDP 41641, so the client commands are the same whether your tailnet lives on tailscale.com or on your own Headscale box. The only part that differs is where you approve routes, and both versions are covered below. The NAS behind the gateway, nas01 at 10.20.0.10, is a network namespace on vpn-gw in our lab; on your network it’s whatever LAN you want to reach, so swap 10.20.0.0/24 for your own range.
Prerequisites
The gateway needs very little, but it does need to stay on:
- Ubuntu 26.04 LTS with sudo access (2 GB RAM is plenty)
- A tailscale.com account, or a Headscale server you control
- Outbound TCP 443, UDP 3478 (STUN) and UDP from port 41641
- A second device to test from (another Ubuntu box, a laptop or a phone)
If the server is fresh, run through the Ubuntu 26.04 initial server setup first so it’s patched and on key-based SSH before you wire it into a mesh. Skip it and the mesh just widens who can reach an unpatched box.
Installing Tailscale on Ubuntu 26.04
Tailscale’s install script detects the release and adds the matching apt repository. On our server it printed Installing Tailscale for ubuntu resolute, using method apt, which matters because some older guides add the noble repo by hand and end up with the 24.04 build. Run it on the gateway.
curl -fsSL https://tailscale.com/install.sh | shIf your change policy does not allow piping a script into a shell, run the repo steps yourself. These are the commands the script ran on our box, minus two chmod 0644 calls that the default umask makes redundant.
sudo mkdir -p --mode=0755 /usr/share/keyrings
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/resolute.noarmor.gpg | sudo tee /usr/share/keyrings/tailscale-archive-keyring.gpg >/dev/null
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/resolute.tailscale-keyring.list | sudo tee /etc/apt/sources.list.d/tailscale.list
sudo apt-get update
sudo apt-get install -y tailscale tailscale-archive-keyringThe repo still carries older builds (apt-cache policy tailscale listed 1.104.2 next to 1.104.4), so you can pin a fleet to the release you tested. That is what we’d do on a gateway that other people depend on, because a surprise upgrade restarts tailscaled and drops every tunnel through it.
# https://tailscale.com/changelog
sudo apt-get install -y tailscale=1.104.4
sudo apt-mark hold tailscaleCheck the version and the daemon before you log in.
tailscale version
systemctl status tailscaled --no-pager | head -8
tailscale statusThe service is enabled and running right after install, but it reports Needs login and tailscale status just says Logged out., which is the expected state until the node joins a tailnet:
Go 1.27.3 built this client, which is the toolchain bump that came with the 1.104.2 security fix. If tailscale version shows anything older than 1.104.4, run sudo apt-get install --only-upgrade tailscale before going further, because the Tailscale SSH socket-forwarding fix shown later in this guide (TS-2026-014) only exists from that release on. Going back to an older build needs --allow-downgrades on the install line.
Joining the node to your tailnet
On a tailscale.com tailnet, the first login is one command. Set a hostname you will recognise in the machine list, because that is also the name peers use for MagicDNS and SSH.
sudo tailscale up --hostname=vpn-gwExpect a login.tailscale.com URL, after which the CLI waits. Open it in a browser where you’re signed in, approve the device, and the command returns. For servers you build from scripts, generate an auth key under Settings then Keys in the admin console and pass it instead, so nobody has to click a link.
sudo tailscale up --hostname=vpn-gw --auth-key=file:/root/tailscale.keyCreate that file with sudo install -m 600 /dev/null /root/tailscale.key, then paste the key in with sudo vim /root/tailscale.key. The file: form reads it from there, which keeps it out of shell history and ps output; delete the file and single-use keys once the node is in. Long-lived servers should also have key expiry turned off from the device’s menu on the Machines page, or the gateway drops off the tailnet when its key expires.
Logging in against a Headscale server
Our lab used Headscale 0.29.7 on hs01. If you’d rather run the control plane yourself, our Headscale install guide covers it in depth; the short version we ran is the release .deb, pinned to the version we tested.
# https://github.com/juanfont/headscale/releases
curl -fsSLo /tmp/headscale.deb https://github.com/juanfont/headscale/releases/download/v0.29.7/headscale_0.29.7_linux_amd64.deb # pin: the release tested with Tailscale 1.104.4
sudo apt-get install -y /tmp/headscale.debRight after install, Headscale starts with server_url and listen_addr on 127.0.0.1:8080. That is useless for remote nodes, so point both at the server’s LAN address and give it a policy file path in the same pass.
sudo sed -i 's|^server_url: .*|server_url: http://192.168.1.129:8080|; s|^listen_addr: .*|listen_addr: 0.0.0.0:8080|; s|^ path: ""| path: /etc/headscale/policy.hujson|' /etc/headscale/config.yamlOur policy allows every node to talk to every other node and lets each user SSH into their own machines as any account except root. It is deliberately loose on the network side and strict on SSH, which suits a small team’s lab.
sudo vim /etc/headscale/policy.hujsonPaste the policy and save the file.
{
"acls": [
{"action": "accept", "src": ["*"], "dst": ["*:*"]}
],
"ssh": [
{
"action": "accept",
"src": ["autogroup:member"],
"dst": ["autogroup:self"],
"users": ["autogroup:nonroot"]
}
]
}Now restart Headscale and create a user. We skipped the restart the first time, and every tailscale up sat silent while the tailscaled journal logged dial tcp 192.168.1.129:8080: connect: connection refused, because Headscale was still bound to localhost from the package’s first start.
sudo systemctl restart headscale
sudo ss -ltnp | grep 8080
sudo headscale users create maryOnce ss shows *:8080, log the gateway in with --login-server. The flag is the only difference from a tailscale.com login. Plain HTTP on the LAN is fine for a lab; anything that crosses the internet should sit behind HTTPS, which the Headscale guide sets up. Headscale also leaves node keys without expiry by default, so there’s no key-expiry step to repeat on that side.
sudo tailscale up --login-server http://192.168.1.129:8080 --hostname=vpn-gwInstead of a tailscale.com link, you get a URL on your Headscale server. Opening it shows the registration page, which is where the flow turns: the node isn’t in until someone runs the command it shows on hs01.
- 1auth register command
- 2replace USERNAME
- Copy the auth register command, auth ID included.
- replace USERNAME with the Headscale user that should own the node (
maryhere).
Run it on the Headscale server with the auth ID from your own page. The ID is single use, so a second run fails harmlessly.
sudo headscale auth register --auth-id hskey-authreq-your-auth-id --user maryHeadscale answers Node vpn-gw registered, and back on the gateway the waiting tailscale up prints Success. and exits.
The gateway got 100.64.0.1 from Headscale’s default 100.64.0.0/10 pool. For the second node we used a pre-auth key instead of the browser dance, which is how you’d enrol servers from a script. We set 30 minutes on the key because a leaked key that expires the same afternoon is a small problem, and Headscale keys are single use unless you add --reusable.
sudo headscale preauthkeys create --user 1 --expiration 30mPass the key it prints to tailscale up on ops01. Note that --user takes the numeric ID from headscale users list, not the name, so --user mary fails.
sudo tailscale up --login-server http://192.168.1.129:8080 --hostname=ops01 --auth-key=hskey-auth-your-key-hereWe passed the key inline because it died 30 minutes later anyway; for longer-lived keys use the file: form shown earlier. It returned without a prompt, and tailscale status on ops01 listed both nodes. That is the path to script, because nothing waits on a browser, so a cloud-init file or an Ansible task can enrol a node unattended.
Checking peer connectivity
Before adding routes, prove the two nodes reach each other and see which path they picked, because a relayed path changes what you should expect from the exit node later. Run these from ops01.
ping -c 3 100.64.0.1
tailscale ping vpn-gw
tailscale status
tailscale whoamiOn the first ping we saw 37 ms while the tunnel came up, then about 1 ms after that. tailscale ping confirms the path is direct rather than through a DERP relay, and tailscale whoami (added in 1.102.1) shows which user, machine and tailnet this node is logged into.
If a peer shows relay "nai" or another region code instead of direct, traffic still flows but through Tailscale’s relay servers, with extra latency. tailscale netcheck tells you why. On our gateway it reported working UDP, a nearest relay in Nairobi at 15.7 ms, and a NAT that changes the mapping per destination.
tailscale netcheckThese are the lines worth reading in the report, with our public address replaced by a documentation IP.
Report:
* UDP: true
* IPv4: yes, 203.0.113.10:46792
* IPv6: no, but OS has support
* MappingVariesByDestIP: true
* CaptivePortal: false
* Nearest DERP: Nairobi
* DERP latency:
- nai: 15.7ms (Nairobi)
- jnb: 58.2ms (Johannesburg)
- par: 127.6ms (Paris)UDP: false means something blocks outbound UDP and every peer will relay over TCP 443. MappingVariesByDestIP: true is the harder NAT type; two nodes that both sit behind one can end up relayed even with UDP open.
Advertising a subnet route
A subnet router lets peers reach machines that can’t run Tailscale, such as a NAS, an IPMI port or a printer. Before enabling forwarding, we advertised the route on purpose to see what Tailscale 1.104.4 does when the gateway can’t actually forward. The client has reported that as a health check since 1.98.2 (1.98.1 added it, but its Linux build was withdrawn for a MagicDNS regression):
sudo tailscale set --advertise-routes=10.20.0.0/24
tailscale statusThe warning lands at the bottom of tailscale status. We then tried the older habit of re-running tailscale up with the new flag, which added two more warnings and refused to apply.
Two lessons sit in that capture. tailscale up now insists you repeat every non-default flag, so a gateway with a login server, a hostname and routes needs tailscale set for changes, which edits one setting and leaves the rest alone. And with forwarding off, the route still looks fine on paper: later, once we had approved it and ops01 had accepted it, curl http://10.20.0.10/ timed out until forwarding was on, because the gateway dropped the packets. Skip the next step and peers get a route that goes nowhere, with no error on their side.
Enabling IP forwarding and UDP GRO
Ubuntu 26.04 ships with both forwarding sysctls at 0. These are the commands from Tailscale’s subnet router docs, and because they write to /etc/sysctl.d they survive a reboot.
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.confBy the time we re-ran tailscale status 15 seconds later, the health check line was gone. The UDP GRO warning is about throughput, not correctness, and one ethtool call on the interface that carries the default route clears it.
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 offethtool settings vanish on reboot. Ubuntu Server runs networkd-dispatcher, so a hook in routable.d reapplies it whenever the link comes up.
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
sudo /etc/networkd-dispatcher/routable.d/50-tailscaleAfter that, the full tailscale up line that the error suggested ran with no warnings at all, so the gateway now passes every check the client runs on it. Get here before adding the exit node, because the exit node depends on the same forwarding settings and fails the same silent way.
Approving the route
An advertised route does nothing until the control plane approves it. On tailscale.com, open the Machines page, find the device with the Subnets badge (or filter with property:subnet), open its Subnets section, select the route and save. On Headscale it is two commands.
sudo headscale nodes list-routes
sudo headscale nodes approve-routes --identifier 1 --routes 10.20.0.0/24The route moves from Available to Approved and Serving as soon as the second command returns.
Approval isn’t the last gate. Linux peers ignore advertised routes until they opt in, which stops a misconfigured router from hijacking everyone’s traffic. Opt in on ops01 and test the route.
sudo tailscale set --accept-routes
ip route show table 52 | grep 10.20
curl -s -m4 http://10.20.0.10/Before the opt-in, 10.20.0.10 went out through the LAN gateway and timed out. After it, Tailscale’s routing table 52 carries the subnet on tailscale0, the web page on nas01 answers, and tracepath shows one hop through 100.64.0.1.
The pmtu 1280 in that trace is the tunnel’s MTU, so large transfers to the NAS ride smaller packets than they would on the LAN. By default the gateway also source-NATs subnet traffic, so the NAS sees requests from 10.20.0.1; turning that off with sudo tailscale set --snat-subnet-routes=false only makes sense if the NAS needs real client addresses and your LAN routes 100.64.0.0/10 back to the gateway. Don’t do it on a box that is also an exit node: we tried it on vpn-gw later and the CLI warned straight away.
Warning: --snat-subnet-routes=false is set with --advertise-exit-node; internet traffic through this exit node may not work as expectedThe same text showed up as a health check in tailscale status until we set it back to true. If you need real client IPs on the LAN, give the subnet router its own box.
Turning vpn-gw into an exit node
An exit node carries all of a peer’s internet traffic, not just one subnet. It uses the same forwarding sysctls, so on a gateway that already routes a subnet it is one more setting. The gateway doesn’t have to be a full VM. A small container can do it too. Our guide to a Tailscale subnet router and exit node in a Proxmox LXC container covers the TUN passthrough it needs first.
sudo tailscale set --advertise-exit-nodeOn tailscale.com, approve it from the device’s Edit route settings with Use as exit node; your policy also needs a rule whose destination covers autogroup:internet. On Headscale, the exit node shows up as 0.0.0.0/0 and ::/0, and you approve them together with the existing subnet, because approve-routes replaces the list rather than adding to it. Leave the subnet out and the NAS route disappears.
sudo headscale nodes approve-routes --identifier 1 --routes 10.20.0.0/24,0.0.0.0/0,::/0Then pick the exit node on the peer. --exit-node-allow-lan-access keeps the peer’s own LAN (its printer, its router) reachable while everything else goes through the tunnel.
tailscale exit-node list
sudo tailscale set --exit-node=vpn-gw --exit-node-allow-lan-accessChecking the first hop is the quickest proof. Before the switch, ops01 went straight to its LAN router; afterwards the first hop is 100.64.0.1 and tailscale status labels vpn-gw as the exit node.
We also turned forwarding off again with the exit node in use. When we checked 20 seconds later, the same health check was back (its wording still says “Subnet routing”), and restoring the sysctl file cleared it. That makes tailscale status on the gateway the first thing to check when a laptop on an exit node reports “no internet”. If you’d rather carry the exit node in your bag than run it on a server, a GL.iNet router can act as a Tailscale exit node too, and our travel router picks for WireGuard and Tailscale compare the models that run the client well.
Enabling Tailscale SSH
Tailscale SSH lets tailscaled answer SSH on port 22 of the Tailscale address and decide access from the tailnet policy instead of authorized_keys. Tailscale’s docs warn that turning it on hangs any existing SSH session you have to the host’s Tailscale IP, so run it from a console or over the LAN address.
sudo tailscale set --sshFrom ops01, which has no SSH private key at all, plain ssh to the MagicDNS name logs straight in. Root is refused, because the policy above only allows autogroup:nonroot.
ssh mary@vpn-gw "hostname; whoami"
ssh root@vpn-gw trueThe -v output proves who answered: the server identifies as Tailscale and authentication is none, because the WireGuard identity already proved who you are.
The last two lines show two separate guards on Unix socket forwarding. The first is an allowlist that Tailscale SSH has enforced for several releases: only sockets under the user’s home, /tmp and /run/user/<uid> can be forwarded, so /run/rootonly.sock was rejected before any permission check. The second is the 1.104.4 fix for TS-2026-014, where forwards used to run as root: the root-owned 0600 socket we put under /tmp now fails with permission denied, because the forward runs with mary‘s own permissions. A socket mary owns at /home/mary/app.sock still forwarded and answered, so tools that tunnel to their own sockets keep working.
The tailscaled journal on the gateway logs every session with the tailnet user, the local user and the source node, which is the audit trail you lose with shared keys.
ssh-session(sess-20261102T162958-cc689035ee): access granted to mary as ssh-user "mary"
audit: SSH login: user=mary uid=1000 from=100.64.0.2 ts_user=mary node=ops01.example.com.On tailscale.com, the default policy is stricter than our lab file: "action": "check" for your own devices, as root or non-root, which asks you to re-authenticate in a browser every 12 hours. Editing the ssh section replaces that default, and deleting it turns Tailscale SSH off for the tailnet. For a shared tailnet, define a tag, put the servers under it and name the accounts people may log in as. Tailscale’s docs warn that autogroup:nonroot on a tagged destination lets every source user log in as any non-root account on those boxes, so list the accounts instead. Merge these keys into your existing policy rather than replacing the file. Tailscale SSH also needs a network rule that lets the source reach tag:server on port 22, and a policy holding only this block would cut every other connection too. Each server joins the tag with sudo tailscale set --advertise-tags=tag:server.
{
"tagOwners": {
"tag:server": ["autogroup:admin"]
},
"ssh": [
{
"action": "check",
"src": ["autogroup:admin"],
"dst": ["tag:server"],
"users": ["ubuntu", "deploy"]
}
]
}Keep OpenSSH on the LAN address as a fallback until you’ve logged in over Tailscale SSH from every machine that needs it. Locking yourself out of a gateway is the one mistake here that needs console access to fix, so test the new path before you close the old one.
Approving routes and SSH in the admin console
Our lab didn’t use a tailscale.com account, so we can’t show the hosted console from our run. These are the places Tailscale’s current docs send you, worth knowing because the console now lives at console.tailscale.com (login still happens on login.tailscale.com, and old /admin/ links redirect):
- Machines page, filtered by
property:subnetorproperty:exit-node - The device’s Subnets section, to approve routes
- Edit route settings, then Use as exit node
- Disable key expiry, in each server’s device menu
- Access controls, which holds the
sshpolicy section
To skip manual approval on gateways you build often, add autoApprovers for a tag in the policy and enrol the gateway with that tag. Both tailscale.com and Headscale support it, and it saves a trip to the console every time you rebuild the box.
Running ufw and systemd alongside Tailscale
We enabled ufw on vpn-gw with Ubuntu’s defaults (deny incoming, deny routed) and only OpenSSH allowed, then rebooted the gateway to check that everything persisted.
sudo ufw allow OpenSSH
sudo ufw --force enable
sudo iptables -S INPUT | sed -n 2,3pTailscale’s own ts-input and ts-forward chains are jumped to before ufw’s, so tailnet pings, the subnet route, the exit node and Tailscale SSH all kept working with no ufw rule for tailscale0. After the reboot, forwarding was still 1, the GRO hook had run, and ops01 reconnected directly.
The flip side is that ufw rules don’t filter tailnet traffic either; your Tailscale policy does. If you configure ufw on Ubuntu 26.04 to restrict what a peer can reach on the gateway, it won’t, so put those limits in the policy file. The daemon itself is an ordinary systemd unit, and these four commands cover most days.
sudo systemctl restart tailscaled
sudo journalctl -u tailscaled -f
sudo tailscale down
sudo tailscale uptailscale down disconnects without logging out, and a bare tailscale up brings the node back with its saved settings. That makes it the safe way to pull a gateway off the tailnet for maintenance, but peers using it as an exit node lose internet until it returns, so warn them first.
Picking the right Tailscale pattern
The three features overlap, and turning all of them on by default makes a gateway harder to reason about. Match the feature to the request in front of you.
| The request | Use | Why not the others |
|---|---|---|
| Reach a NAS, IPMI or printer that can’t run Tailscale | Subnet route | An exit node would push all of the peer’s traffic through the gateway for one device |
| A laptop on hotel Wi-Fi should browse from the office IP | Exit node | A subnet route only covers listed ranges |
| Stop copying SSH keys to every server | Tailscale SSH | Routes and exit nodes don’t decide who gets a shell |
| One always-on box in a small office | Subnet route and exit node on the same host | Add Tailscale SSH once there’s a second server to manage |
| Join two office LANs | A subnet router on each side, --accept-routes where needed | An exit node would drag one office’s internet across the link |
For a small team, start with a subnet route and one exit node on a box that never sleeps, and add Tailscale SSH when a second server makes key distribution a chore. If you run plain WireGuard on Ubuntu 26.04 today, run both side by side for a week and move services to the 100.x addresses before you switch WireGuard off. The same client works on Fedora and Rocky Linux and AlmaLinux, and inside a Proxmox LXC container with the TUN device passed through.
Keeping the gateway healthy
A gateway is the box everyone notices when it breaks, so give it a short routine and stick to it.
- Read
tailscale statusafter every change - Hold the package with
sudo apt-mark hold tailscale - Keep key expiry disabled on the gateway
- Watch
journalctl -u tailscaledforReceived error
The hold is a judgment call. Tailscale shipped security fixes for Tailscale SSH and Serve in 1.98.9, 1.98.10, 1.102.1 and 1.104.4, so a held gateway falls behind fast. We’d hold it to avoid surprise restarts during the work week and lift the hold once a month: sudo apt-mark unhold tailscale, upgrade, then check tailscale status and one SSH login before walking away. Pair that with Fail2ban on Ubuntu 26.04 if OpenSSH still listens on a public address, because Tailscale does nothing for the port it doesn’t own.
