Sooner or later every NAS owner wants to reach their files, Plex library or admin pages from outside the house. The wrong answer is forwarding DSM, SSH or SMB ports on your router. The right answer is a VPN, and for home labs in 2026 that usually means a choice between plain WireGuard and Tailscale, which is built on WireGuard.
This post compares them honestly and gives a working setup for each, so you can pick in five minutes rather than five evenings.
The short answer
- Choose Tailscale if your ISP uses CGNAT (common on Australian NBN fixed wireless, 5G home internet and some budget plans), if you don't want to open any router ports, or if you want family members' devices connected with minimal fuss.
- Choose plain WireGuard if you have a real public IP, you're comfortable forwarding one UDP port, and you'd rather not depend on a third-party coordination service.
Both encrypt traffic with the same WireGuard protocol, and neither lets anyone read your data in transit.
How they differ
WireGuard is a protocol and a small kernel module. You write the configs: keys, addresses, allowed IPs and an endpoint. One side must be reachable from the internet, which means a public IP plus a forwarded UDP port. It's simple, fast and completely self-hosted. My WireGuard server guide walks through a full setup.
Tailscale uses WireGuard for the tunnels but adds a coordination service that hands out keys, tracks where each device is and punches through NAT. Devices sign in with an identity provider (Google, Microsoft, GitHub and so on), and each gets a stable 100.x.y.z address plus a MagicDNS name like nas.tailnet-name.ts.net. When a direct connection is impossible, traffic falls back to Tailscale's encrypted DERP relays.
| Plain WireGuard | Tailscale | |
|---|---|---|
| Router port forward | One UDP port | None |
| Works behind CGNAT | No (unless the server side has a public IP) | Yes |
| Key management | Manual | Automatic |
| Third-party dependency | None | Coordination server (or self-hosted Headscale) |
| Cost | Free | Free personal plan |
| Adding a new phone | Generate keys, edit config, QR code | Install app, sign in |
The big practical differences are the port forward, CGNAT and key management.
The Synology catch with WireGuard
DSM's VPN Server package offers OpenVPN, L2TP/IPSec and PPTP, but not WireGuard. To run WireGuard you have three options:
- Run it on your router. Many routers (OpenWrt, pfSense/OPNsense, UniFi, recent ASUS and some ISP-supplied models) include a WireGuard server. This is the cleanest option because the VPN then reaches your whole LAN, NAS included.
- Run it on another always-on Linux box like a Raspberry Pi, using the configs from my WireGuard guide.
- Community packages or containers on the NAS. These depend on your model's kernel supporting WireGuard, and DSM updates can break them. They're fine for tinkering, but I wouldn't rely on them for the only way into your network.
The Synology advantage with Tailscale
Tailscale publishes an official Synology package, so setup is genuinely quick:
- Install Tailscale from Package Center.
- Open it, click Log in, and approve the device in your browser.
- Install Tailscale on your laptop and phone and sign in with the same account.
Your NAS is now reachable at its MagicDNS name or 100.x address from anywhere, with no ports opened. DSM, SMB, Synology Photos and SSH all work over it.
Two DSM 7 limitations are worth knowing:
- Outbound connections from the NAS are off by default. DSM 7 sandboxes packages, so other apps on the NAS (for example Hyper Backup to another tailnet device) can't reach the tailnet. Tailscale's docs fix this with a boot-up task in Control Panel > Task Scheduler that runs as root:
/var/packages/Tailscale/target/bin/tailscale configure-host; synosystemctl restart pkgctl-Tailscale.service
- The package can advertise routes but can't accept them. It can act as a subnet router for your home LAN, but it can't use routes advertised by other subnet routers.
If the DSM firewall is on, allow traffic from 100.64.0.0/10 (mask 255.192.0.0) or tailnet connections will be dropped.
Sharing your whole LAN (subnet router)
To reach other devices at home (a printer, a router admin page, a Pi) through the NAS, advertise your LAN subnet. Over SSH on the NAS:
sudo /var/packages/Tailscale/target/bin/tailscale set --advertise-routes=192.168.1.0/24
Then approve the route in the Tailscale admin console. Clients on Linux need --accept-routes; the macOS, Windows, iOS and Android apps accept approved routes by default.
Plain WireGuard on a router: the minimum config
If you go the self-hosted route, the server side on a Linux router looks like this. Your router's WireGuard UI will ask for the same values:
[Interface] Address = 10.8.0.1/24 ListenPort = 51820 PrivateKey = <server private key> [Peer] # phone PublicKey = <phone public key> AllowedIPs = 10.8.0.2/32
And on the phone:
[Interface] Address = 10.8.0.2/32 PrivateKey = <phone private key> DNS = 192.168.1.1 [Peer] PublicKey = <server public key> Endpoint = home.example.com:51820 AllowedIPs = 192.168.1.0/24, 10.8.0.0/24 PersistentKeepalive = 25
AllowedIPs on the phone is a split tunnel: only traffic for your home LAN goes through the VPN, and everything else uses the phone's normal connection. Forward UDP 51820 on your router, and use DDNS for home.example.com if your IP changes.
Performance
On the same connection, plain WireGuard and a direct Tailscale connection perform almost identically, because they're the same protocol. Your home upload speed is nearly always the limit, not the VPN. The exception is when Tailscale can't make a direct connection and uses a DERP relay; then throughput drops noticeably. Run tailscale status and look for relay versus direct. Double NAT on both ends is the usual cause.
Privacy and trust
With plain WireGuard, nothing leaves your control. With Tailscale, the coordination service sees device metadata (names, IPs, when they connect) but not your traffic, which stays end-to-end encrypted. If even that's too much, Headscale is an open-source, self-hosted coordination server compatible with the Tailscale clients. It needs a server with a public IP, which brings back the port-forward problem.
Security either way
- Keep DSM behind the VPN rather than on the open internet, and never forward SSH. My Synology SSH hardening guide covers the rest.
- With Tailscale, use access controls (ACLs) so a shared device can only reach what it needs, and turn on key expiry for laptops.
- With WireGuard, give every device its own key pair, and remove the peer when a device is lost.
- For apps you deliberately want public, use a reverse proxy with HTTPS instead of a VPN. See Synology reverse proxy with Let's Encrypt.
My recommendation
For most home NAS owners, especially behind CGNAT, install the Tailscale package and be done in ten minutes. If you already run a router with WireGuard built in and have a public IP, plain WireGuard is just as good and fully self-hosted. Either way, close every port you were forwarding for remote access, and your NAS gets a lot safer overnight.
Comments (0)
No comments yet. Be the first to leave one!
Leave a Comment