Usenet
Photo of author

How to Set Up Tailscale on Unraid for Secure Remote Access

Unraid Tailscale is the pairing of an Unraid server with the official Tailscale plugin, creating a private WireGuard-based mesh network that lets you reach your NAS, its web interface, and your self-hosted services from anywhere without opening a single port on your router.

If you have been nervously port-forwarding to reach your Unraid server from a hotel or a friend’s couch, an unraid tailscale setup replaces that whole habit. Instead of publishing your NAS to the internet and hoping the firewall holds, every device you own joins one encrypted tailnet and talks directly to the server.

For anyone maintaining a growing archive of large datasets, open-source software, and public domain material, the practical upside is simple. Your download client, your archival data organizers, and your file shares all become reachable privately, on the same names and ports you use at home.

The setup takes about ten minutes. What follows is the order we use on real builds: prepare the tailnet, install the plugin, verify the device, then layer on MagicDNS, HTTPS certificates, subnet routes, exit nodes, and per-container identities.

Why Private Mesh Access Works for a Home Lab

A mesh VPN gives every device in your tailnet a stable private address and a direct encrypted tunnel to the others, which is exactly what a NAS needs. The result is remote access that behaves like being on your own LAN, with no static IP, no dynamic DNS, and no inbound firewall rules.

How Tailscale Differs From a Traditional VPN

Traditional VPNs funnel all traffic through one concentrator you have to host, harden, and expose. Tailscale builds on WireGuard and connects peers directly, using its coordination service only for key exchange and discovery.

That peer-to-peer design means your laptop in a coffee shop talks straight to the Unraid box. Latency stays low, transfers of large datasets stay fast, and there is no single gateway to overload.

When Direct Device Access Is Safer Than Port Forwarding

Port forwarding publishes a service to every scanner on the internet. Within an hour of opening a management port, logs fill with credential-stuffing attempts, and that pressure never stops.

With a tailnet, nothing is listening publicly. A device has to be authenticated and authorized before it can even see the server, which shrinks your attack surface to almost nothing.

Access Models for a NAS, Web Interface, and Home-Lab Services

Most home labs settle into three patterns worth knowing before you start:

Access modelBest forNotes
Server node onlyWeb interface, SMB/NFS, SSHSimplest; bridge-mode containers ride along on the same address
Subnet routerPrinters, switches, other LAN gearOne approval exposes an entire local range
Per-container nodeSharing one service, custom networksEach container gets its own machine name and certificate

Start with the server node. Add the others only when a real need appears.

Install and Authorize the Official Plugin

Unraid 7 ships with native ts.net certificate support, and the plugin originally built by Derek Kaser is now maintained inside the Lime Technology repositories. Installation is a two-part job: create the tailnet first, then authenticate the server.

Preparing Your Tailnet Before Connecting the Server

Sign up at Tailscale using an identity provider you actually control, such as a Google, Microsoft, or GitHub account with two-factor authentication enabled. That login becomes the master key to your entire private network.

Before adding devices, turn on MagicDNS in the admin console and decide whether new machines require manual approval. Setting those defaults first saves a cleanup pass later.

Installing the Unraid Tailscale Plugin

Open the Apps tab, search for Tailscale, and install the plugin, not the Docker container. The plugin runs independently of the Docker service, so remote access survives a stopped array or a failed container start.

Once installed, a Tailscale entry appears under Settings. This is where the daemon status, authentication link, and advanced flags live.

Connecting Through the Tailscale Admin Console

Click the authentication link the plugin generates and approve the request in your browser. The page confirms which tailnet the server is joining, so check the account name if you manage more than one.

After approval, the settings page shows a 100.x.y.z address and a green connected state. That address works immediately from any other device already signed in.

Verifying Device Approval and Machine Names

In the admin console, confirm the new machine appears and rename it to something predictable like tower or archive-nas. Machine names feed MagicDNS, so a clean name now means shorter URLs forever.

We also recommend disabling key expiry on the server node. Otherwise the tunnel drops every few months, usually while you are away and least able to fix it.

Reach the Server and Shares Privately

With the node online, the same services you use at home become reachable by name. MagicDNS handles resolution, trusted TLS certificates remove browser warnings, and file shares mount over the tunnel exactly as they do on the LAN.

Using MagicDNS Instead of Memorizing Addresses

MagicDNS turns 100.94.13.7 into tower.your-tailnet.ts.net. Every device with Tailscale running resolves that name automatically, no hosts file edits required.

Short names work too when devices share a tailnet. Typing tower in a browser is a small quality-of-life win you will use daily.

Opening the Web Interface With Tailscale HTTPS

Enable HTTPS certificates in the admin console, then use Unraid 7’s built-in ts.net certificate support. The server requests a real TLS certificate for its MagicDNS name, so the web interface loads over https:// with a valid padlock.

This matters more than it sounds. Valid certificates mean no click-through warnings, which keeps you from getting numb to the ones that actually matter.

Connecting to SMB and NFS Shares

On Windows, map a drive to \tower.your-tailnet.ts.netdata. On macOS, connect to smb://tower.your-tailnet.ts.net, and on Linux mount NFS against the same name.

Two field notes: use the MagicDNS name rather than the LAN hostname to avoid discovery quirks, and expect browsing in Network Neighborhood to stay empty. Direct paths work; broadcast-based discovery does not cross the tunnel.

Managing the Server With Tailscale SSH

Tailscale SSH lets your tailnet identity authorize shell access, so key management moves into the admin console. Enable it in the plugin’s advanced options, then define who may connect in your access rules.

Sessions can be recorded and revoked centrally, which is a genuine upgrade over scattered authorized_keys files. For scripted backups, this pairs well with rsync running over the same encrypted path.

Extend Access With Routes and Exit Nodes

Two optional features turn the server into a gateway: subnet routing exposes your local network to remote devices, and exit node mode pushes your remote traffic out through your home connection. Both require approval in the admin console before they take effect.

When to Advertise a LAN Subnet

Advertise a subnet when you need gear that cannot run Tailscale itself, such as a managed switch, an IPMI interface, or a network printer. One route covers the whole range.

Skip it if the Unraid server is all you need. Fewer exposed paths means fewer things to audit later.

Approving Routes in Edit Route Settings

Set the advertised range in the plugin, then open the device in the admin console and use Edit route settings to approve it. Routes sit dormant until approved, which is the step most people miss.

On client devices, also enable accept routes. Without it, the client ignores the advertised range even though the server is publishing it correctly.

Using the Server as an Exit Node

Enabling exit node mode lets phones and laptops route all internet traffic through your home line, which is useful on untrusted hotel or airport Wi-Fi. Approve the exit node in the admin console after enabling it.

Keep expectations accurate: traffic leaves from your home IP address, so this is a trust decision, not an anonymity tool. When we want provider-level privacy for archival downloads, we still rely on SSL from the Usenet provider itself and a commercial VPN where appropriate.

Choosing an Exit Node From iOS

In the iOS app, tap the tailnet menu, select Exit Node, and pick the Unraid server. A small VPN indicator confirms the tunnel is active.

If the option appears greyed out, the node is usually still awaiting approval. Approve it in the admin console, then toggle the app connection off and on.

Give Docker Services Their Own Identities

Containers on standard bridge networks already answer on the server’s Tailscale address, so most stacks need nothing extra. Installing Tailscale inside a container becomes worthwhile when you want per-service names, individual sharing, or support for custom network modes.

When Individual Container Access Makes Sense

Give a container its own node when it runs on ipvlan or macvlan (a br0 address), when you want to share one service with another Tailscale user without exposing the whole server, or when a service needs its own certificate.

Adding the Tailscale sidecar variables in the container template is enough. Each container then shows up as a separate machine in the admin console.

Using Reverse Proxying and Trusted Certificates

With Tailscale Serve, a container can publish itself over HTTPS at its own ts.net name with a valid certificate. That removes the need for a public-facing reverse proxy, wildcard DNS records, and renewal cron jobs.

Practical example: a download client such as SABnzbd gets sabnzbd.your-tailnet.ts.net on port 443. Clean URL, real TLS, nothing exposed publicly. Pair it with a premium Usenet provider like Newshosting or Easynews so the retention and SSL side of your archival pipeline is as solid as the network side.

Testing Compatibility Before Protecting Critical Services

Some applications dislike being served from a subpath or behind an unexpected hostname. Test with a non-essential container first and confirm logins, API callbacks, and websockets still work.

Keep the original port binding available during testing. Rolling back should take seconds, not an evening.

Separating Archival Tools and AI Workloads

Splitting nodes by role keeps troubleshooting sane. Archival data organizers and API synchronization hubs sit on one identity, while GPU-backed AI or indexing workloads get another.

That separation also lets you share a single tool with a collaborator, an approach we see often in the preservation-focused write-ups on datahoarder.io, without handing over access to the entire server.

Maintain a Secure and Reliable Configuration

A tailnet is low maintenance, not zero maintenance. Quarterly reviews of devices, keys, and route approvals prevent slow drift, and a written recovery plan keeps a bad update from locking you out while you are on the road.

Apply Least-Privilege Access Rules

By default every device in a tailnet can reach every other device. Editing the access rules to restrict traffic by user, tag, and port narrows that considerably.

Tag the Unraid server, then allow only your own devices to reach management ports. Guests you share a single container with should never see SSH or the web interface.

Review Devices, Keys, and Route Approvals Regularly

Open the admin console and remove machines you no longer own, including old phones and rebuilt VMs. Rotate or delete auth keys that were only needed once.

Check approved routes at the same time. It is easy to approve a broad range during setup and forget it is still live a year later.

Plan for Service Updates and Connectivity Troubleshooting

Plugin updates occasionally restart the daemon, so avoid applying them right before you travel. Keep the plugin current anyway, since fixes for exit node and container quirks land regularly.

When a connection fails, work outward: check the daemon status in Settings, then MagicDNS resolution, then whether the client has accept routes enabled.

Document Recovery Steps for Remote Administration

Write down how to regain access if the tunnel drops: local IPMI, a second node on the same LAN, or a trusted household member who can reach the physical console. Store credentials somewhere you can open from a phone.

Disabling key expiry on the server and running a second Tailscale node at home, such as a small single-board computer, has saved us more than one trip. Redundancy costs almost nothing here.

Frequently Asked Questions

How do I set up Tailscale on an Unraid server?

Create a Tailscale account and enable MagicDNS, then install the Tailscale plugin from the Apps tab and open Settings > Tailscale. Click the authentication link, approve the device in the admin console, and the server becomes reachable at its 100.x address or MagicDNS name.

Should I use the Tailscale plugin or a Docker container on Unraid?

Use the plugin for the server itself, because it runs independently of Docker and keeps working even when the array is stopped. The Docker container is for advanced cases only, such as containers on br0 networks or giving a single service its own machine name.

How can I configure Unraid as a Tailscale subnet router?

Enter your LAN range, for example 192.168.1.0/24, in the plugin’s advertised routes field, then approve that route under Edit route settings for the device in the admin console. Remote clients also need accept routes enabled before the range becomes reachable.

How do I enable and use an exit node on Unraid?

Turn on exit node advertising in the plugin settings, then approve the exit node for that device in the admin console. On a client, select the server under the exit node menu, and all internet traffic will route through your home connection.

Why is the accept routes option greyed out in Tailscale?

The option is usually unavailable because no routes have been advertised or approved yet, so there is nothing for the client to accept. Confirm the route is published by the server and approved in the admin console, then reconnect the client app.

How do I reauthenticate Tailscale on Unraid?

Open Settings > Tailscale, log the node out, then click the new authentication link and sign in again with the same account. Disabling key expiry for that device in the admin console prevents the need for repeat reauthentication while you are away.

About the Author

Don is a tech enthusiast with a passion for datahoarding, privacy, and security. He has been involved in technology for over a decade, working in various roles such as a desktop support engineer, network administrator, and IT consultant. Don's extensive experience in the tech industry has given him a deep understanding of how technology works and how to use it to its fullest potential.

Don is particularly interested in topics such as VPNs, privacy and IRC, which are all related to data privacy and security. He believes that protecting our digital privacy is essential, especially in today's world where data breaches and cyber attacks are becoming more common. Don has dedicated himself to educating himself and others on how to protect their digital privacy and stay safe online.

In addition to his tech expertise, Don is also an avid gamer. He enjoys playing video games in his free time, and is also a family man who enjoys spending time with his wife and children. He believes that technology should enhance our lives and bring us closer together, and he strives to promote this message through his work.