CGNAT blocks ordinary IPv4 port forwarding at the ISP edge, but it does not prevent secure NAS remote access. The right solution uses NAT traversal, a relay, public IPv6 or a reachable gateway.
If your ISP uses CGNAT, stop troubleshooting the home port-forward rule
First confirm that your router’s WAN address does not match the public address seen from the internet or falls inside shared/private space. Then choose a path that does not require unsolicited IPv4 connections to reach your home router. Tailscale is the simplest default for most NAS owners because it attempts NAT traversal and can relay encrypted traffic when direct connectivity is impossible. Advanced users can use a VPS plus WireGuard, native IPv6, or request a public IPv4 address from the ISP.
What is your best CGNAT workaround?
Pick the constraint that matters most and use the least complicated architecture that satisfies it.
Choosing a NAS for remote use behind CGNAT?
Compare current NAS options while considering CPU headroom, Docker support, vendor remote-access software and network interfaces for your home-server plan.
Prices and availability are pulled from Cloudzat’s existing Amazon catalogue and can change. As an Amazon Associate, Cloudzat earns from qualifying purchases.
What CGNAT changes for a NAS
Carrier-grade NAT places an additional translation layer inside the ISP network. Your home router receives an address that is not directly reachable from the public IPv4 internet, and the ISP maps many customers through shared public addresses. The 100.64.0.0/10 block is reserved for shared address space and is a common clue, although providers can use other topologies. A port-forward rule on your own router controls only your router; it cannot instruct the ISP’s upstream NAT to deliver unsolicited traffic to you.
That is why a NAS can be perfectly configured locally and still fail every external connection test. The solution is architectural, not another round of forwarding-rule edits. Use a connection method in which the NAS initiates outbound connectivity, use a publicly reachable relay or gateway, use globally routed IPv6 with firewalling, or obtain a public IPv4 address from the ISP.
How to tell whether CGNAT is actually the problem
Open your router or gateway status page and note the WAN IPv4 address. Then compare it with the public IPv4 address reported by a reputable external IP check. If the addresses differ substantially, or the router WAN address is in private/shared space, there is likely another NAT upstream. Traceroute and ISP documentation can provide additional evidence. Some mobile/fixed-wireless providers explicitly state that public IPv4 is an add-on.
Do not diagnose CGNAT only because one application is unreachable. A local firewall, double NAT between two home routers, or an incorrect service bind can produce similar symptoms. Confirm the topology first. If you have two routers under your control, bridge one or place the inner router in the correct mode before blaming the ISP. The goal is to distinguish an upstream boundary you cannot configure from a home-network boundary you can.
Tailscale is the simplest default because it is built around NAT traversal
Tailscale devices make outbound connections to coordinate a private WireGuard-based network. They then attempt to establish direct peer-to-peer paths through NAT. This removes the dependency on a conventional inbound port-forward rule and is why Tailscale is popular for NAS access behind CGNAT. The remote laptop addresses the NAS by its Tailscale identity or private overlay address instead of trying to reach the home router’s shared IPv4 address.
When a direct path cannot be created, Tailscale can use a DERP relay. Traffic remains end-to-end encrypted, but performance can be lower than a direct connection. For administration, file browsing and many backup tasks this is still far more useful than having no path at all. For very large transfers, inspect whether the session is direct or relayed before judging NAS performance.
ZeroTier is another private overlay option
ZeroTier can also create a virtual private network between authorized devices and is included in current TrueNAS remote-access guidance. It is worth considering if you already operate ZeroTier networks or prefer its network-controller model. Like Tailscale, the key advantage under CGNAT is that the solution does not rely on an ordinary public IPv4 listener on your home router.
Use access rules deliberately. A virtual network can become too broad if every device can reach every subnet and service. For a NAS, grant remote users only the resources they need. Administration, backups, media playback and general family file access do not necessarily require identical permissions. Private overlay technology reduces public exposure, but least privilege still matters inside the overlay.
A VPS plus WireGuard gives advanced users a self-controlled public rendezvous point
If you want to own the reachable endpoint, rent a small VPS with a public IP and establish a WireGuard tunnel from the home network to the VPS. The home side initiates the connection through CGNAT, while remote clients connect to the VPS. Routing can then send traffic for the NAS subnet down the established tunnel. This pattern works because the only public listener is the VPS, which you control.
The design is more work than Tailscale. You must secure the VPS, manage keys, configure forwarding, control firewall rules, prevent accidental open relaying, monitor updates and understand return routes. Do not route the entire home network simply because it is easy to add 0.0.0.0/0. Publish the smallest private prefixes and services necessary. A VPS is an infrastructure component, not a magic checkbox.
A public IPv6 address can bypass the IPv4 CGNAT problem, but it is not a security feature
Many ISPs that use IPv4 CGNAT still provide globally routable IPv6. If the NAS network and remote client both have usable IPv6, you can build a direct WireGuard or other private path without requiring a public IPv4 address. The important difference is that IPv6 normally does not rely on NAT for isolation. The firewall becomes the primary boundary, so do not interpret “globally routable” as “safe to expose.”
Prefer a VPN listener or other narrow authenticated service rather than publishing the NAS management UI and file-sharing ports over IPv6. Verify that router firewall rules apply to IPv6, because a household that carefully blocks IPv4 can accidentally leave a broad IPv6 path open. Test from an external IPv6-capable network and document the rules just as you would for IPv4.
Asking the ISP for a public IPv4 address may be the cleanest answer
Some providers will remove CGNAT for free, offer a dynamic public IPv4 add-on, or sell a static IP. If you need conventional inbound connectivity for several services, paying a small monthly fee can be simpler than maintaining relays and workarounds. Once you have a public address, you can run a normal WireGuard gateway with one well-secured inbound port instead of publishing individual NAS services.
A public IP does not mean you should go back to forwarding SMB, DSM or QTS directly. It simply restores your ability to host a private VPN endpoint. Keep the same least-exposure design. The best outcome is often public reachability for one hardened VPN gateway and private access to everything behind it.
A consumer commercial VPN usually does not solve inbound CGNAT access
Connecting the NAS to Surfshark, NordVPN or another commercial provider creates an outbound tunnel to the provider. Websites then see the provider’s exit address. That does not automatically create a provider-side route that lets your laptop initiate a private connection back to the NAS. Some VPNs support limited port-forwarding features, but even that is an application-specific inbound port through the provider, not a full replacement for a private remote-access network.
Use commercial VPNs for outbound privacy and use Tailscale, WireGuard, ZeroTier or a vendor service for private administration. If both are active, verify routing carefully. A full-tunnel commercial VPN can change the default route and break the return path for your remote-management overlay unless local and overlay networks are explicitly preserved.
Plex behind CGNAT is related but should be treated as a separate service problem
Plex remote access traditionally benefits from a reachable inbound path. Behind CGNAT, automatic router configuration cannot create a mapping through the ISP’s upstream NAT. For a private household where approved devices can run Tailscale, a private overlay can be a practical way to reach Plex without making the server public. That is different from offering normal Plex remote access to arbitrary clients that are not members of the private network.
Do not make NAS administration public simply to fix Plex. Keep the media service and management plane separate. Cloudzat’s Plex CGNAT and Plex-without-port-forwarding guides focus on the media-specific choices, while this page focuses on general NAS reachability. Separating the services prevents a convenience workaround from becoming a storage-security problem.
Backup and replication jobs need stable addressing more than a public home IP
A remote backup target often works well over Tailscale or a site-to-site WireGuard path because the peers can use stable private addresses even when the home public IP changes. This is usually safer than exposing rsync, SMB or a backup application directly to the internet. For large nightly backups, direct peer connectivity and ISP upload speed become important; a relayed overlay path may be adequate for incremental changes but slower for initial seeding.
Seed large datasets locally where practical, then use the private network for incrementals. Restrict backup credentials to the required dataset and avoid reusing the NAS administrator account. CGNAT changes reachability, but it does not change the basic backup principle: a remote copy should have narrow credentials and should not become an unrestricted path back into the primary NAS.
Measure the remote path before buying faster NAS hardware
A CGNAT workaround introduces network variables that do not exist on the LAN. A relay, VPS region, ISP upload cap, mobile-network latency or MTU issue can reduce throughput even when the NAS has 10GbE and fast NVMe cache. Test a large transfer and record the VPN path, home upload speed, remote download speed and CPU use. Compare that with a local transfer so you know which layer is actually limiting performance.
For Tailscale, identify direct versus relayed connectivity. For a VPS design, choose a nearby region with sufficient transfer allowance and network capacity. For IPv6, confirm both ends have stable working IPv6. Performance tuning becomes straightforward once the topology is known; without that information, every slow transfer looks like a NAS problem.
Choose the least complicated CGNAT solution that gives you a private recovery path
For most NAS owners, Tailscale is the lowest-friction choice. For users already invested in ZeroTier, it can fill a similar private-overlay role. For advanced self-hosters who want full control, a VPS WireGuard hub is powerful. Native IPv6 can be elegant when both ends support it, while an ISP public IPv4 add-on can make a conventional private VPN gateway straightforward again.
Whichever path you choose, retain local access that does not depend on the remote service. Store recovery keys and MFA backup codes safely, remove old devices, and do not turn a CGNAT workaround into a reason to publish file-sharing and administration ports. CGNAT is a routing constraint, not a requirement to weaken NAS security.
Sources and methodology
Cloudzat checks current platform and vendor documentation before publishing networking guidance. NAS operating systems, VPN clients, remote-access services and provider features can change, so confirm the current instructions before modifying a production server.
Research snapshot: August 24, 2026. Recheck current platform and VPN documentation before changing a production network.