This document describes, step by step, how to deploy a Tailscale Subnet Router on a Synology NAS using Docker.
It’s written to be repeatable and production‑friendly, and includes cleanup, (re)install, verification, troubleshooting, and day‑2 operations.
Goal
Access your home LAN (e.g.,192.168.1.0/24) from your laptop/phone over Tailscale as if you’re on the couch at home — without port‑forwarding, and with minimal exposure to the public Internet.
tailscale/tailscale) acting as a subnet router.192.168.1.0/24) into your Tailscale tailnet.tun device is present on the NAS: ls -l /dev/net/tun → should existNote on permissions/state
We store Tailscale state on disk so the node survives reboots. We’ll also use a small helper container to delete state safely when needed (avoids “permission denied” issues).
We’ll use this path on Synology:
/volume1/docker/tailscale
Create it (if not present):
mkdir -p /volume1/docker/tailscale
cd /volume1/docker/tailscale
Files we’ll place here:
docker-compose.yml – container definition.env – contains your TS_AUTHKEYstate/ – persistent Tailscale state (keys, node identity)It’s a good idea to fully clean old attempts before (re)deploying.
cd /volume1/docker/tailscale
# Stop and remove any previous deployment
docker compose down 2>/dev/null || true
docker rm -f tailscale 2>/dev/null || true
# Wipe previous state using a root helper container
docker run --rm --user root -v "$(pwd)/state:/state" busybox sh -c 'rm -rf /state/*'
# Ensure the state directory exists
mkdir -p state
ls -lah state
You should see an empty state/ directory afterward.
.env File (Auth Key)Create .env in /volume1/docker/tailscale with your reusable key:
TS_AUTHKEY=tskey-REPLACE_WITH_YOUR_REAL_AUTHKEY
You can rotate this key at any time in the Tailscale Admin Console, then recreate the container.
docker-compose.ymlUse host networking (no port mappings necessary), mount the tun device, and advertise your LAN:
services:
tailscale:
image: tailscale/tailscale:latest
container_name: tailscale
hostname: opthoekie # the name that will appear in Tailscale Admin
restart: unless-stopped
# Put the container directly on the NAS network stack
network_mode: host
# Needed for the tun device and routing
cap_add:
- NET_ADMIN
- NET_RAW
devices:
- /dev/net/tun:/dev/net/tun
# Persist Tailscale state across restarts/reboots
volumes:
- ./state:/var/lib/tailscale
# Core configuration
environment:
# 1) Provide auth key via .env
- TS_AUTHKEY=${TS_AUTHKEY}
# 2) Persist state here
- TS_STATE_DIR=/var/lib/tailscale
# 3) Advertise your LAN (change if your subnet differs)
- TS_ROUTES=192.168.1.0/24
# 4) Don’t push DNS from this container (keep client DNS)
- TS_ACCEPT_DNS=false
# 5) Extra flags to tailscale up (explicitly keep accept-routes false on the router)
- TS_EXTRA_ARGS=--accept-routes=false
# 6) Hostname inside your tailnet
- TS_HOSTNAME=opthoekie
# 7) Timezone (optional)
- TZ=Europe/Amsterdam
Why
network_mode: host?
It simplifies routing and avoids hairpin/iptables complexity on Synology — ideal for a clean subnet-router setup.
cd /volume1/docker/tailscale
docker compose pull
docker compose up -d
Check status:
docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Image}}"
docker logs --tail=100 tailscale
docker exec tailscale tailscale status
You should see your node (hostname opthoekie) in the list.
Open the Tailscale Admin Console → Machines → click opthoekie → Edit route settings:
192.168.1.0/24 (or your subnet)You may also need to enable the Subnets badge (Admin → Machines → it should show “Subnets”).
sudo tailscale up --accept-routes=true
After this, your client will install routes to
192.168.1.0/24viaopthoekie.
You can now access things like192.168.1.101(your NAS), Unifi controller, printers, etc.
From your Mac (with Tailscale connected):
# Reach NAS (example)
ping 192.168.1.101
# Hit a local HTTP service on your LAN
curl -I http://192.168.1.101
From the NAS/container side:
docker exec tailscale tailscale ip
docker exec tailscale tailscale status
You should see the node online, and clients connected.
The Admin Console should list opthoekie with the Subnets badge and route approved.
opthoekie-1 in AdminThat’s a previous identity. Remove it from Admin → Machines (… → Expire).
After our cleanup + fresh state, only the new opthoekie should remain.
Use the helper container we showed earlier:
docker run --rm --user root -v "$(pwd)/state:/state" busybox sh -c 'rm -rf /state/*'
--accept-routes is false warningThat’s fine on the subnet router; the router only advertises routes.
Clients must accept routes (GUI/CLI above).
opthoekie.We set TS_ACCEPT_DNS=false so the router doesn’t push DNS.
Clients keep their own DNS; you can configure MagicDNS later if desired.
cd /volume1/docker/tailscale
docker compose pull
docker compose up -d
.env with the new TS_AUTHKEY.docker compose down && docker compose up -d/volume1/docker/tailscale/ (especially state/).docker compose up -d.cd /volume1/docker/tailscale
docker compose down
# Optional: wipe identity/state if you’re retiring the node
docker run --rm --user root -v "$(pwd)/state:/state" busybox sh -c 'rm -rf /state/*'
192.168.1.0/24).Q: Can I still reach the NAS’s web UI via the tailnet IP?
A: Yes. You can use the NAS’s private IP (192.168.1.101) or the router’s own Tailscale IP for services that bind on the host.
Q: Do I need Unifi port‑forwards anymore?
A: No. Remove any old WireGuard or port‑forwarding rules you created for VPN — Tailscale doesn’t need them.
Q: Can I make the NAS an exit node?
A: Yes; set TS_EXTRA_ARGS=--advertise-exit-node and enable it in Admin. Clients can then choose it as an exit node. (Subnet routing and exit node can co‑exist.)
Q: MagicDNS?
A: Optional. If you enable MagicDNS in Admin, clients can resolve hostname.tailnet-name.ts.net and any private DNS you configure.
# Deploy / Update
cd /volume1/docker/tailscale
docker compose pull
docker compose up -d
# Show node status
docker exec tailscale tailscale status
# Show node IPs
docker exec tailscale tailscale ip
# Clean wipe (state)
docker compose down
docker rm -f tailscale 2>/dev/null || true
docker run --rm --user root -v "$(pwd)/state:/state" busybox sh -c 'rm -rf /state/*'
You’re done. You can now use your LAN from anywhere as if you’re home — securely, without port‑forwarding, and with minimal upkeep.