A practical NAS guide to commercial VPN routing, Plex remote access, Tailscale and the network decisions that keep streaming stable.
Do not route Plex through a commercial VPN by default
For most NAS owners, keep Plex on the normal WAN or a private Tailscale path and route only privacy-sensitive containers through a commercial VPN. Plex remote access normally expects a reachable path to TCP 32400, while provider VPNs primarily solve outbound privacy.
What are you trying to achieve with Plex?
Select the outcome you actually need. The right architecture changes when the goal is private remote access, outbound privacy, container isolation or Plex stability.
Need a NAS for Plex? Live Amazon NAS listings
Compare current Synology, QNAP and UGREEN NAS listings while planning Plex, Docker and remote-access workloads.
Prices and availability are pulled from Cloudzat’s existing Amazon catalogue and can change. As an Amazon Associate, Cloudzat earns from qualifying purchases.
What a VPN changes in a Plex NAS setup
A Plex server normally needs two different kinds of connectivity: reliable local access inside the home and a predictable path for remote clients when you are away. A commercial privacy VPN changes the server's outbound route and public IP address, but it does not automatically create a usable inbound path back to Plex. That distinction is the foundation of a stable design. If a Synology, QNAP, Unraid or TrueNAS host sends all traffic through a provider VPN, Plex may report that remote access is unavailable even while ordinary web browsing from the NAS still works. The VPN is doing its job, but the path expected by Plex is no longer the same path the router can reach from the public internet.
The safest approach is to decide why you want the VPN before enabling it. If the goal is private remote access to the server itself, an overlay network such as Tailscale is usually a better fit. If the goal is to give a downloader or another container a different public IP address, isolate only that application behind the commercial VPN. If the goal is simply to stream Plex remotely, direct Plex remote access or a private mesh connection is usually cleaner than tunneling the whole NAS through a consumer VPN.
Plex remote access and TCP port 32400
Plex Media Server listens on TCP port 32400 for its main service. With normal automatic remote access, Plex relies on UPnP or NAT-PMP when those features are available on the router. With a manual configuration, the public external TCP port you choose must be forwarded to TCP 32400 on the Plex server. The important point is that the public-side port does not have to be 32400, but the internal destination on the server is normally 32400. That gives administrators flexibility while preserving the port Plex expects locally.
A commercial VPN can break this arrangement because the server's outbound connection may leave through the VPN provider while the router's forwarded inbound connection still arrives through the ISP. That creates asymmetric routing or a public-IP mismatch. Some VPN providers also do not offer inbound port forwarding at all. In that case, forwarding a port on the home router cannot make the provider's VPN exit address accept unsolicited inbound traffic. Test the normal ISP path first, then add VPN routing selectively so you know which change caused a remote-access failure.
Direct connections are better than Plex Relay
Plex includes Relay as a fallback when a direct remote connection cannot be established. Relay can be useful because it preserves basic access when NAT, firewall or routing conditions prevent a direct path. It should not be treated as the performance target for a NAS media server, however. Plex currently documents a maximum Relay video stream rate of 2 Mbps, which is dramatically lower than the bitrate of many 1080p and especially 4K files. A server that seems to work remotely through Relay can still deliver a poor experience once higher-quality media is requested.
When you test a VPN change, check whether the client says it is using an indirect or relayed connection. Do not judge success only by whether the library opens. A direct connection should be the goal for ordinary remote Plex use where practical. If you intentionally use Tailscale, the traffic is private between tailnet devices and you do not need Plex Relay to solve the same reachability problem. The key is to know which path is carrying the stream rather than letting several fallback systems mask a routing problem.
Commercial VPN versus private remote-access VPN
The phrase “Plex VPN” is ambiguous. Surfshark, NordVPN, Proton VPN and similar services are designed primarily to send internet-bound traffic through provider-operated exit servers. Tailscale and a self-managed WireGuard deployment are primarily used to create private connectivity between devices you control. Both use encrypted tunnels, but their network roles are different. Treating them as interchangeable is one of the most common sources of confusing NAS advice.
For Plex, a provider VPN is useful when a specific container needs outbound privacy or a different exit location. A private overlay is useful when you want your phone, laptop or streaming device to reach the NAS as though the devices shared a private network. It is entirely possible to use both, but the routes must be deliberate. Keep Plex and remote-management traffic on the path that preserves reachability, while directing only the applications that need commercial VPN egress through the provider tunnel.
The cleanest NAS architecture for Plex plus a VPN
On a capable NAS, the cleanest architecture is usually application-level routing. Keep DSM, QTS, Unraid management, TrueNAS administration, SMB and Plex on the normal LAN/WAN route. Put only the workload that actually needs commercial VPN egress behind a dedicated tunnel. Docker makes this practical because a VPN gateway container such as Gluetun can own the tunnel while selected application containers share its network namespace. The rest of the server remains unaffected.
This design has operational benefits beyond Plex. Backup jobs can continue reaching cloud destinations through the normal route. Tailscale can continue providing private management access. Local clients can discover and reach Plex without depending on the provider tunnel. If the commercial VPN goes down, the privacy-sensitive container can stop while the NAS itself remains usable. That is a much better failure mode than making every storage, media and administration service depend on a third-party VPN endpoint.
Split tunneling and policy routing
Split tunneling is simply the policy decision that some traffic should use the VPN and other traffic should not. On desktop systems this may be exposed as an application setting. On a NAS, the mechanism is more often container networking, policy routing on a router, a separate VLAN, or a host-level WireGuard interface assigned only to selected workloads. The implementation matters less than the outcome: Plex should keep the route it needs for remote access, while the privacy-sensitive application uses the commercial VPN.
Verify both directions after configuring the split. From inside the VPN-routed container, check the public IP address and DNS resolver. From the Plex server, confirm the public route remains the expected ISP path unless you intentionally designed otherwise. From a remote client, confirm the connection is direct and that playback works at realistic bitrate. A split-tunnel design is only successful when it preserves both privacy for the selected workload and predictable reachability for Plex.
CGNAT changes the remote-access equation
Carrier-grade NAT means your ISP places another NAT layer upstream of your router. In that situation, even a perfectly configured port-forwarding rule on the home router may not be reachable from the public internet because the router does not own a unique public IPv4 address. Buying a commercial VPN does not automatically solve this. Most privacy VPN services are designed for outbound sessions and do not hand you a generally reachable inbound port on their exit address.
If CGNAT is the obstacle, use an architecture built for NAT traversal. Tailscale is particularly attractive because it attempts direct peer-to-peer connections and can use relays when direct NAT traversal is not possible. Another option is obtaining a public address from the ISP if offered. A reverse proxy or VPS tunnel can also work for advanced users, but it adds more infrastructure and security responsibility. The correct solution is determined by the inbound reachability problem, not by whether the service is marketed as a VPN.
Local LAN access must stay predictable
A Plex NAS is usually doing more than serving Plex. It may also host SMB shares, backups, photo libraries, Docker applications and administration interfaces. A VPN route that accidentally captures local subnets can make those services appear to vanish even though the server itself is healthy. Always preserve local RFC1918 routes explicitly when the VPN client or container firewall would otherwise send them into the tunnel.
With Gluetun, for example, local subnet access can be permitted deliberately through firewall configuration. With a router policy rule, local traffic should continue using the LAN rather than being sent to a commercial VPN gateway. With Tailscale, remember that subnet-router and exit-node roles are different. A subnet router exposes selected private subnets to the tailnet, while an exit node can route general internet traffic. Do not enable an exit node merely because your goal is to reach Plex on the NAS.
DNS, discovery and why the library can disappear
Plex problems after enabling a VPN are not always caused by port forwarding. DNS selection, local discovery, route priority and firewall rules can all change. A container behind a VPN may receive provider DNS servers and lose access to local hostnames. A host-level tunnel may install a default route with a lower metric. A kill switch may block private subnets. The result can look like a Plex application problem even though the root cause is network policy.
Troubleshoot in layers. First confirm the NAS can reach the gateway and local clients. Then verify the Plex service is listening locally on TCP 32400. Next test the public IP used by Plex. Check whether the router sees the expected port mapping and whether the client is direct or indirect. Finally verify DNS and any container firewall. Working methodically prevents you from changing several settings at once and making the network harder to understand.
Security: expose less, not more
Remote media access is convenient, but a NAS often contains far more valuable data than the Plex library. Do not respond to a connectivity problem by opening a large range of ports or exposing the NAS administration interface directly to the internet. Plex's main service port and the management interfaces of DSM, QTS, Unraid and TrueNAS are separate concerns. Keep administrative access behind a private VPN or another strongly authenticated remote-access method whenever possible.
Plex also documents several local discovery and companion ports, but those are not a reason to forward all of them publicly. The remote-access path should be as narrow as possible. Use strong account security, keep Plex Media Server and the NAS operating system patched, and review router rules after testing. A temporary troubleshooting port forward has a habit of becoming permanent if it is not deliberately removed.
When a newer NAS makes the VPN problem easier
VPN routing itself rarely requires an expensive NAS, but modern hardware can make the overall media-server architecture easier to manage. More CPU headroom helps when Plex must transcode while containers and storage jobs are active. More RAM gives Docker workloads room to operate without competing aggressively with filesystem caches. Faster 2.5GbE or 10GbE networking can help local direct-play and large file transfers, although it does not make a slow WAN connection faster.
The bigger buying question is software flexibility. A NAS that handles container networking cleanly makes it easier to isolate a downloader behind Gluetun while leaving Plex on the normal route. Models with mature Docker or container support are therefore often a better fit for advanced VPN/media setups than entry-level systems that only expose one host-level VPN client. The live Amazon NAS block above is meant to surface current enclosure options, not to imply that buying new hardware is required to fix a routing mistake.
A practical test sequence before you call the setup finished
Start with the VPN disabled and confirm local Plex playback plus normal remote access. Record whether the remote connection is direct, what public IP the NAS uses, and whether Plex reports remote access as fully reachable. Then enable the proposed VPN path only for the intended workload. Recheck the public IP from that workload and verify that Plex's own route did not change. Test from a device that is genuinely outside the home network rather than relying on Wi-Fi behavior that may hairpin through the router.
Finally, restart the VPN container or tunnel and confirm the policy survives a reboot. Stop the VPN deliberately and verify the protected container does not leak through the normal WAN. At the same time, make sure Plex and NAS administration remain reachable through their intended paths. A good architecture is not just one that works once. It should fail predictably, recover cleanly and make it obvious which services depend on which network path.
Sources and methodology
Cloudzat checks current vendor and platform documentation before publishing networking guidance. VPN clients, NAS operating systems, container images and remote-access behavior can change, so verify the current vendor instructions before modifying a production server.
Research snapshot: August 24, 2026. Recheck current platform, VPN and container documentation before changing a production network.