Guide

Synology NAS Remote Access Behind CGNAT

Do not put DSM on the public internet. Synology's own guidance is to limit internet exposure of the NAS and restrict admin access, and 2026 has given three separate reasons why: CVE-2026-13639 and CVE-2026-13684, both rated CVSS 9.8, let an unauthenticated attacker read and write arbitrary files, and CVE-2026-32746 allows unauthenticated remote command execution. A NAS is usually also the backup, so a compromise does not cost you one machine — it costs you the thing you were going to restore from. QuickConnect is free, built by Synology for exactly this, and works through carrier-grade NAT. Start there.

Option 1: QuickConnect, free and built for this

QuickConnect is Synology's own remote access and it needs no port forwarding, which is why carrier-grade NAT does not stop it: your NAS makes an outbound connection to Synology and your client is introduced to it.

It tries three things in order, and knowing which one you get explains the speed you see:

  1. Direct. Your client asks Synology for the NAS's registered addresses and connects straight to it. On your own LAN this is as fast as typing the IP.
  2. Hole punching. Each side opens a temporary port on its own NAT and Synology introduces them. Traffic then flows directly, at close to port-forwarded speed.
  3. Relay. If neither works, everything goes through a Synology relay server. This is the slow one, and behind CGNAT it is often where you land.

That third stage is the honest caveat: it is free, but your traffic is passing through Synology's infrastructure and the throughput is theirs to shape. For browsing files and checking on things it is fine. For pulling a large restore over it, less so.

Option 2: Tailscale, if it is only you

Free at household scale, works through CGNAT, exposes nothing. Synology publishes Tailscale as a package for DSM 7, installable from the Package Center, which makes this considerably less fiddly than it used to be.

Your laptop and phone join a private network with the NAS. DSM, SMB shares, Synology Photos, all reachable as though you were at home, and none of it on the public internet. For a household this is the best combination of speed and safety on this page.

The limit is the usual one: only devices on your network can reach it. Sharing a folder with someone outside, or letting an external service pull from the NAS, needs something else.

Option 3: a public address — for a service, never for DSM

This is what we sell, so weigh it accordingly, and note that the advice narrows it rather than widening it.

There are real cases: a service on the NAS that external users or systems must reach directly, an offsite backup target another machine writes to, a self-hosted app on a port a relay will not carry.

Do not put DSM's management interface on that address. Ports 5000 and 5001 are DSM itself — the admin interface, the thing the CVEs above are about. Give the public address to the specific service, on its own port, and leave DSM reachable only over your LAN or your mesh.

curl -fsSL https://tunnelnet.io/install.sh | sudo bash
sudo tnet status

# the ONE service port, and no default protocol, deliberately --
# a UDP service with a TCP rule fails silently
sudo tnet ports allow tcp 8096          # e.g. a media server
sudo tnet ports mode                    # confirm what is open

# 5000 and 5001 are DSM. Do not open them.

If a container on the NAS can run the daemon instead of the NAS itself, better still: the blast radius of that container is smaller than the blast radius of DSM.

Why a NAS deserves more caution than a web server

Three things make it a worse thing to expose than almost anything else in a house:

None of that means Synology builds bad hardware — it means a NAS is a high-value target and the honest posture is to keep its management surface off the public internet entirely.

If anything on it is reachable, harden first

Choosing, honestly

Get a public IP — $10/mo See all plans

Sources

Related