Why does CGNAT break your remote desktop connection?

Your home router already uses Network Address Translation (NAT) every single day. It's how all the devices on your private network — whether that's your PC, your phone, or your smart TV — can share the single public IP address your Internet Service Provider (ISP) gives you. Your router hands out private IP addresses, like `192.168.1.x`, to those devices. When your PC sends data to the internet, your router stamps the packet with its single public IP address. When the internet replies, your router remembers which internal device asked for what and sends the data to the correct private IP address. This is how it's always worked, and it's essential.

This standard NAT isn't a problem; it's a necessary part of how the internet functions. It's the reason many devices can share one internet connection without each needing its own expensive, unique public IP address. IPv4, the most common internet protocol, would have run out of unique addresses long ago if NAT hadn't come along to help share them. Without it, every single device online would need its own globally routable IP, and that's just not how things are built.

Now, Carrier-Grade NAT (CGNAT), also called Large Scale NAT (LSN), layers on top of that. It's a *second* layer of NAT. Your ISP, dealing with the worldwide shortage of IPv4 addresses, puts many, many customers behind a *single* public IPv4 address on their network. This means your home router's 'public' IP address — the one it gets from your ISP — isn't really public at all. It's a private IP address within your ISP's much bigger internal network. You'll often see this internal IP fall within the `100.64.0.0/10` range (that's `100.64.0.1` to `100.127.255.254`), or sometimes other private ranges like `10.0.0.0/8`. Your entire home network, with its own router and private addresses, is now just one of many private networks all sharing a single external identity on the internet. This setup makes it impossible to reach your specific home directly from the outside.

Let's go back to the phone number idea. Standard NAT is like your house having a unique street address, and your router is the local post office that knows to deliver mail for 'Joe' to the living room and 'Jane' to the bedroom. CGNAT is like your entire street sharing *one* single street address with several other streets in the neighborhood. Even if you tell the main post office your specific house number, they only see the shared street number and don't know which specific house, let alone which person inside, to send mail to. Without a unique public IP for your router, there's no way for an external service to initiate a connection directly to your home network, no matter what settings you tweak on your local router.

When you try to connect to a remote desktop, your client software usually sends a request to your host PC's public IP address and a specific port number — say, port `3389` for RDP. If you had a truly public IP and port forwarding set up, your home router would see this incoming request to its public IP and send it to the right internal IP address and port of your host PC, like `192.168.1.100:3389`. This direct path is the bedrock for many remote access solutions that rely on you doing the manual setup, assuming your router has a truly public IP.

For traditional remote access to work, your router needs a unique public IP address that the internet can actually see and target. When you configure port forwarding on your home router, you're telling *your router* how to send specific incoming traffic to a device on your internal network. This setup is perfect when your router has a public IP address that's directly visible and addressable from the wider internet.

With CGNAT, the public IP address your client tries to connect to isn't actually your router's. It belongs to your ISP's CGNAT device, which is handling traffic for potentially hundreds or thousands of customers. Your router's port forwarding rules are completely invisible to this upstream CGNAT device. The ISP's CGNAT device has no idea where to send that incoming traffic among the many customers sharing that single public IP. It just drops the connection attempt. This means your carefully configured port forwarding becomes totally useless because the connection is blocked at a layer above your control, right inside your internet service provider's infrastructure.

Many CGNAT setups use what's called Symmetric NAT. This is particularly strict because it demands that incoming packets come from the exact same IP address and port that an outgoing packet was sent to. If your remote access client tries to start a connection from a new IP or port combination that hasn't previously sent traffic *to* your host PC, the CGNAT device will simply block it. This makes 'hole punching' techniques, which try to establish a direct connection by having both sides send outbound traffic at the same time, much harder to pull off. This strictness means that even advanced tricks for direct connections often fail, showing why you need other ways to connect.

The most fundamental fix for the IPv4 address shortage and NAT is to move to IPv6. With IPv6, every device gets its own globally unique IP address, completely removing the need for NAT. If both your ISP and your remote access client device support end-to-end IPv6 connectivity, direct connections become simple, no port forwarding needed. But, full IPv6 rollout is still happening, and many networks, especially older ones or mobile hotspots, might not fully support it yet. If IPv6 is fully available to you, it absolutely solves the problem, but it's still a work in progress for widespread adoption.

A Virtual Private Network (VPN) can offer a way around this by building an encrypted tunnel from your host PC to a VPN provider's server. Some VPN services offer dedicated public IP addresses or let you forward ports through their network. By connecting your host PC to such a VPN, it essentially gets a new 'public' IP address that's reachable from the internet, skipping your ISP's CGNAT entirely. Services like NordVPN or ExpressVPN (though not all of them offer port forwarding or dedicated IPs) can be used for this. A VPN can make your host PC reachable, but it adds an extra hop, which might increase latency, and it requires paying for a service that specifically supports port forwarding or dedicated IPs.

Many remote desktop solutions use relay servers as a solid way to get past CGNAT. Both the client and the host PC make outbound connections to a third-party intermediary server. Since firewalls or NAT devices (including CGNAT) rarely block outbound connections, this path almost always works. The relay server then acts as a middleman, sending data between the client and the host. Services like TeamViewer, AnyDesk, and Chrome Remote Desktop primarily use this setup. This method guarantees you can connect almost anywhere, but all your data passes through a third-party server, and connection performance depends on the relay server's network capacity and how close it is to you.

Sometimes, you can just ask your Internet Service Provider for a public IPv4 address. Some ISPs offer this as a premium service, often for business accounts, or sometimes for a small extra monthly fee for home customers. Getting a dedicated public IP address takes your connection out from behind CGNAT, letting you set up port forwarding on your own router just like you normally would. This is a direct solution that gets rid of CGNAT, but it depends entirely on your ISP's rules and might cost you more.

Axiom is built with a hybrid connectivity approach specifically to reliably get around network headaches like CGNAT. When you try to connect, Axiom first attempts to set up a direct peer-to-peer connection between your client and host devices. This path is always going to give you the lowest possible latency. If network conditions — whether that's CGNAT, strict firewalls, or other complex network setups common in places like hotels, corporate networks, or university campuses — stop a direct connection from forming, Axiom automatically spots this and switches over to using its secure relay servers. This smart system means Axiom handles the tricky network stuff for you, always finding the best available path without you needing to manually step in or troubleshoot anything.

The main advantage of this design is that you never need to mess with port forwarding or router configuration to use Axiom. You just install the Axiom software once on the Windows PC you want to reach remotely. That host PC then gets a unique, short numeric connect ID. To start a session, you connect from any modern browser on your client device, type in this ID, and your pre-set access password. The system takes care of all the connection details, whether it's direct or relayed. This removes all the frustration and technical barriers of setting up network configurations, making remote access straightforward and available from pretty much anywhere.

No matter if you're on a direct or relayed path, all Axiom sessions are encrypted, keeping your data safe while it travels. For those who need serious performance, like for remote gaming, Axiom's gaming mode aims for smooth `60fps` video, something we achieve with hardware encoding on a discrete-GPU gaming PC. What's more, mouse and keyboard input travels on its own dedicated low-latency channel, totally separate from other traffic like file transfers or audio streams. Your remote desktop experience puts both security and responsiveness first, even when facing tough network conditions or demanding tasks.

While direct connections give you the best latency, using relay servers naturally adds a small amount of extra network delay because of that extra hop. For example, in July 2026, I did some informal testing myself. I used a Windows gaming PC host and a browser client on the same laptop, both connected through a US mobile phone hotspot. I saw about `10ms` of added latency compared to a home Wi-Fi connection. This minor increase is a necessary trade-off for making sure you can connect universally and reliably across all sorts of diverse and restrictive network environments. You can count on solid access from almost anywhere, with the understanding that a very slight latency increase might happen when a relay is necessary.