QNAP NAS Remote Access for MSPs: Reach QTS Without myQNAPcloud or Port Forwarding

Almost every small business an MSP looks after keeps its files on a QNAP NAS, and sooner or later you need to reach it from somewhere other than the server room: to log into QTS or QuTS hero, apply a firmware update, check a failing disk, restore a file someone deleted, or open an SSH session to fix a stuck service. The question is how you get to that admin interface without turning the NAS into an internet-facing target, and the two default answers both have real drawbacks for a managed fleet.

This guide shows how to give your team browser access to every QNAP NAS across your client sites over one outbound tunnel, with no static IP, no open ports, and no reliance on QNAP's own cloud relay.

Why the usual QNAP remote-access options fall short

QNAP's built-in answer is myQNAPcloud. Its CloudLink component holds an outbound connection from the NAS to QNAP's relay servers and hands you a SmartURL, so remote clients connect to QNAP's relay instead of straight to your NAS, and no port forward is needed. That works for a single home unit, but for an MSP it has two problems: every session is routed through QNAP's third-party cloud, and it only ever reaches the NAS itself. The NVR, the PBX, the switch and the hypervisor on the same site are still out of reach, so you end up with a different access method for every class of device.

The other common answer is worse. Plenty of admins simply forward the QTS web port to the internet, usually 8080 for HTTP or 443 for HTTPS, so they can log in from a browser anywhere. That is exactly the exposure the DeadBolt ransomware campaigns hunted for. In its own security advisory QSA-22-24, QNAP told customers to disable port forwarding on the router and stop exposing the NAS to the internet, after thousands of internet-facing units were encrypted. A NAS admin console holds your clients' data and their backups. It should never answer an unsolicited connection from the public internet.

Reach the whole LAN through one tunnel

ProxyLink works from the inside out. You install one WireGuard tunnel on the site's router or gateway: a MikroTik, a pfSense or OPNsense box, an OpenWrt router, or any Linux host down to a Raspberry Pi. The tunnel dials outbound to ProxyLink and holds itself open with a keepalive, so the site never accepts an inbound connection, needs no static IP, and works fine behind carrier-grade NAT. Declare the LAN, and any additional VLANs, as subnets on the tunnel and every device on them becomes reachable, the QNAP included, with nothing installed on the NAS at all.

The links you create

Once the tunnel is up, you create a proxy link per service on the NAS:

• QTS web interface (HTTPS): an HTTPS proxy link to the NAS on its admin port gives you the full QTS or QuTS hero desktop in a browser tab, File Station, Storage and Snapshots, Control Panel and all. ProxyLink's default appliance mode rewrites the Origin and Referer headers so the NAS's built-in same-origin check accepts the proxied request, the same handling that makes Synology DSM, UniFi and pfSense web UIs work through it.
• SSH: QNAP enables SSH from Control Panel under Network and File Services, on port 22 by default and for administrator accounts only. A ProxyLink browser SSH terminal puts you on that shell with no client on your laptop, for the jobs the web UI will not do.
• File services: because the proxy carries any TCP port over the tunnel, you can also create a link to the NAS's file-sharing port when you genuinely need a mount, though File Station in the QTS web UI covers most file work without one.

What this looks like for an MSP

One tunnel per client site covers the NAS and everything else on the network through the same peer. An engineer opens ProxyLink, clicks the site's QNAP, and is on the QTS login in a browser with no VPN client to launch and no SmartURL to manage per device. Every session is tied to an engineer identity, with the target IP, port, start time and duration recorded, and access requires a ProxyLink login. The NAS keeps zero open inbound ports and stays invisible to the internet scans that DeadBolt relied on. Traffic runs over open WireGuard, and the relay is hosted in the EU on German infrastructure with no third-party routing of the session.

Access is scoped through the team model: each client is a group, engineers are granted only the sites they manage, and peer isolation keeps every customer's traffic separate at the network layer. The NAS vendor's cloud is one less dependency, the data stays off the public internet, and the same browser tab reaches the rest of the rack.

Try ProxyLink free at app.proxylink.dev, no card required, free during early access. Setup guides for MikroTik, pfSense, OPNsense and Linux gateways are in the docs.