A decision guide for NAS owners whose router port forward cannot work because the ISP controls another NAT layer upstream.
CGNAT is an upstream reachability problem
If the ISP uses CGNAT, a local router port forward may never be reachable from the public internet. For private devices, Tailscale is usually the cleanest workaround. For broad public Plex sharing, ask the ISP for a public IPv4 address before building a complex tunnel.
What is your CGNAT constraint?
Select the outcome you actually need. The right architecture changes when the goal is private remote access, outbound privacy, container isolation or Plex stability.
Planning a new Plex NAS? Live Amazon NAS listings
A network fix may not require new hardware, but current NAS options can add better Plex, Docker and storage headroom.
Prices and availability are pulled from Cloudzat’s existing Amazon catalogue and can change. As an Amazon Associate, Cloudzat earns from qualifying purchases.
Why CGNAT breaks ordinary Plex port forwarding
Plex remote access traditionally works best when the home router can accept an inbound connection from the public internet and translate it to the Plex server on the LAN. CGNAT adds another NAT device under the ISP's control between your router and the public internet. Your router may show a WAN address, but that address can itself be private or shared. In that situation, forwarding TCP 32400 on your own router does not create a path through the carrier's upstream NAT.
This is why the Plex Remote Access screen can remain red even when the local rule looks perfect. The problem is not necessarily Plex, the NAS firewall or the router. It may be that your household simply does not own a reachable public IPv4 address. Before changing several settings, compare the router's WAN address with the public address reported by an external IP-check service. If they differ significantly or the router uses a known private/shared range, CGNAT is a strong possibility.
Confirm CGNAT before rebuilding the network
Start by checking the WAN address shown on the router. Private ranges such as 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 clearly indicate another NAT layer. ISPs also use the shared 100.64.0.0/10 range specifically for carrier-grade NAT. A different public-looking address can still be behind upstream translation, so compare it with the address visible from the internet.
If you can, ask the ISP whether the connection uses CGNAT and whether a public IPv4 address is available. Some providers offer one free on request, some charge monthly, and some only provide it on business plans. Solving the problem at the ISP layer can be the simplest option if you need normal public Plex sharing. If that is not available, use an overlay or reverse-tunnel architecture rather than repeatedly changing a router rule that can never be reached.
Why a commercial privacy VPN usually does not solve CGNAT
Buying a commercial VPN can give the NAS a different public exit IP, but that does not mean unsolicited inbound connections can reach the server through that address. Provider VPNs are primarily designed for outbound privacy. Many providers do not offer port forwarding, and even those that do may provide a dynamically assigned port with specific conditions. A dedicated IP is also not the same thing as an open inbound port.
For Plex, the requirement is reachability from the remote client back to the server. If the VPN provider does not expose an inbound port that maps through the tunnel to your NAS, the new public IP does not solve the CGNAT problem. Commercial VPNs can still be useful for selected outbound applications, but do not choose one solely because the home ISP uses CGNAT. Use technology designed for private connectivity or obtain a real public endpoint.
Tailscale is a strong private-access answer
Tailscale is attractive behind CGNAT because both the NAS and remote client initiate outbound connectivity to participate in the tailnet. Tailscale then attempts NAT traversal to establish a direct path and can use relay infrastructure when direct peer connectivity is not possible. You do not need to ask the ISP to forward a port through its CGNAT device for your own authorized devices to communicate over the overlay network.
Install Tailscale on a supported Synology, QNAP, TrueNAS SCALE or Unraid system, join the remote devices to the same tailnet, and test the NAS's Tailscale address. For personal remote use, this can be dramatically simpler than maintaining a public-facing service. It is especially well suited to administrative access, SMB, private dashboards and Plex use by devices you control. The tradeoff is that viewers generally need to be part of the private network rather than accessing Plex through the ordinary public internet.
Plex Relay can keep basic access alive, with limits
Plex Relay is another fallback when direct remote access cannot be established. It is convenient because it requires less networking work, but Plex currently documents a maximum Relay video stream rate of 2 Mbps. That is not an ideal target for high-quality home media. A library can appear reachable while large files are forced into aggressive transcodes or simply cannot stream at their intended quality.
Use Relay as a fallback, not as evidence that the network architecture is optimized. If remote streaming matters, determine whether your use case is private access for your own devices or public-style sharing with friends and family. Private devices can often use Tailscale. Broader sharing may justify obtaining a public IPv4 address, using IPv6 where the entire path is correctly configured, or building an advanced reverse-tunnel solution with careful security controls.
Public IPv4 from the ISP may still be the simplest solution
If your ISP can assign a public IPv4 address, that often restores the normal Plex remote-access model with the least moving parts. Once the router truly owns a public endpoint, automatic UPnP/NAT-PMP or a manual TCP port forward can work as expected. You still need secure router and NAS configuration, but there is no additional overlay client required on every remote playback device.
A static address is not mandatory. Dynamic DNS can track a changing public IP if needed, and Plex's own service discovery can handle much of the normal client experience. The important distinction is public reachability, not whether the address is static. Ask specifically for a public IPv4 address rather than assuming a “static IP” product is required. For many users the ISP change is cheaper and simpler than adding another server or tunnel provider.
IPv6 can bypass CGNAT, but only when the whole path supports it
IPv6 gives devices globally routable addresses without relying on IPv4 NAT, so it can remove the specific limitation created by CGNAT. That does not mean you should disable firewalls or expose the NAS broadly. With IPv6, the firewall becomes even more important because the address itself may be globally reachable. Client networks also need compatible IPv6 connectivity for a straightforward end-to-end path.
Treat IPv6 as a network architecture, not a quick checkbox. Verify the ISP delegation, router firewall, NAS address stability and the actual Plex client path. If the household and remote networks have inconsistent IPv6 support, an overlay such as Tailscale can remain easier because it abstracts much of the transport detail. The best choice is the one you can maintain safely, not the one that looks most elegant on a diagram.
Reverse tunnels and VPS options for advanced users
A public VPS can act as the reachable endpoint when the home network is behind CGNAT. The NAS initiates an outbound tunnel to the VPS, and remote traffic enters through the VPS before traversing that established connection back home. WireGuard, reverse proxies and other tunneling tools can implement variations of this design. It is powerful because you control the public endpoint, but it also means you operate an internet-facing server.
This approach is appropriate for experienced administrators who understand firewalling, TLS, authentication, patching and bandwidth costs. It is not automatically better than Tailscale. The VPS becomes part of the availability and security chain, and media traffic can consume significant transfer bandwidth. If you only want private Plex access for your own devices, a managed overlay usually has fewer moving pieces. Use a VPS when you genuinely need public reachability or architectural control that the simpler options do not provide.
Keep the NAS management plane separate
CGNAT can tempt people to solve remote access by opening whatever path finally works. Remember that Plex and NAS administration are different security surfaces. Even if you build a public path for Plex, keep DSM, QTS, TrueNAS and Unraid management private where possible. A Tailscale connection is excellent for administration even when Plex itself uses a public endpoint.
Do not forward a wide range of ports simply because one service is difficult to reach. Plex's main service uses TCP 32400 internally, while local discovery uses other ports that normally do not need public exposure. Keep the public rule narrow, use strong account security, and review logs. The goal is to restore the service you need without accidentally publishing storage administration or unrelated Docker applications to the internet.
NAS performance still matters after reachability is solved
CGNAT is a networking problem, but remote Plex performance can expose hardware limitations after the connection finally works. If a remote client cannot direct play the source file, Plex may transcode. High-bitrate 4K transcodes can be far more demanding than the overlay VPN itself. The NAS also needs enough memory and storage throughput for the rest of its workload.
Choose a new NAS based on bays, CPU/media capability, Docker flexibility, RAM headroom and network ports rather than CGNAT alone. A faster enclosure will not turn a shared carrier address into a public one. It can, however, make the overall Plex experience better once a proper remote path exists. The live Amazon block above is intended to connect network planning with the hardware decision users often make at the same time.
A decision tree that avoids wasted effort
If your router has a real public IPv4 address, use Plex's normal remote-access workflow and troubleshoot the port mapping. If the ISP uses CGNAT but can supply a public address at a reasonable cost, that is often the cleanest route for ordinary Plex sharing. If the viewers are your own devices and can run Tailscale, use the private overlay and avoid public port forwarding entirely. If you need broad public reachability and cannot obtain a public address, consider an advanced reverse-tunnel/VPS design.
Do not buy a commercial privacy VPN as the default CGNAT fix. Use one only when you also need outbound privacy for a specific workload and the provider's inbound features genuinely match the requirement. The fastest route to a stable setup is identifying the exact layer that blocks inbound connections and choosing a technology designed for that layer.
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.