What Is NAT and CGNAT? Why Your Home Server Is Unreachable (And How to Fix It)
You set up a home server, configured port forwarding on your router, opened every relevant port, and tested from your phone. It still does not work. The reason is probably not your server or your configuration. The reason is that your ISP placed you behind Carrier Grade NAT (CGNAT), a layer of network address translation that happens before your router and that you cannot configure or bypass using your own equipment. This guide explains exactly how NAT works, why it was invented, what CGNAT is, how to determine if your ISP uses it, what the 100.64.x.x IP address on your router means, why port forwarding fails under CGNAT, and what your actual options are to make a home server accessible from the internet in 2026.
The Root Cause: IPv4 Address Exhaustion
To understand NAT and CGNAT, you first need to understand why they exist. Both were invented to solve the same problem: there are not enough IPv4 addresses for every device that needs one.
IPv4, the addressing system that the internet still primarily runs on in 2026, uses 32-bit addresses. A 32-bit number can represent exactly 4,294,967,296 unique values (about 4.3 billion). That sounds like a lot, but it is not. Of those 4.3 billion addresses, a significant portion is reserved for special purposes (multicast, loopback, documentation examples, and future use), leaving roughly 3.7 billion usable public addresses. The world has far more than 3.7 billion internet-connected devices.
The depletion of the global IPv4 address pool was not sudden. It was foreseen decades before it happened, and NAT was the primary mechanism invented to delay it. Here is how the exhaustion unfolded:
| Date | Event |
|---|---|
| 1981 | IPv4 defined in RFC 791. With 4.3 billion addresses, no one imagined they would run out. |
| Early 1990s | Rapid internet growth makes it clear that 4.3 billion addresses will not be sufficient. NAT (RFC 1631) is proposed as a stopgap. |
| 1996 | RFC 1918 defines private IP address ranges (10.x.x.x, 172.16.x.x, 192.168.x.x) for use inside private networks. This enables one public IP to serve an entire home or office network via NAT. |
| 1998 | IPv6 is defined in RFC 2460 as the long-term solution. It uses 128-bit addresses, providing 340 undecillion unique addresses. |
| 3 February 2011 | IANA (Internet Assigned Numbers Authority) allocates the last blocks of free IPv4 addresses to the five Regional Internet Registries (RIRs). The global free pool is officially exhausted. |
| 2011 to 2015 | Each RIR exhausts its own free IPv4 pool: APNIC (Asia-Pacific, April 2011), RIPE NCC (Europe, September 2012), LACNIC (Latin America, June 2014), ARIN (North America, September 2015). |
| 2012 | RFC 6598 defines the 100.64.0.0/10 address block specifically for CGNAT deployments, giving ISPs a dedicated IP range for their internal NAT infrastructure. |
| 2026 | IPv4 exhaustion is complete. ISPs cannot obtain new public IPv4 addresses except through the secondary market at high cost. CGNAT is now standard practice at most residential ISPs worldwide. |
What Is NAT (Network Address Translation)?
NAT is a technique implemented in a router or gateway device that translates IP addresses in packet headers as traffic passes through. Its most common application is allowing many devices sharing private (non-routable) IP addresses to communicate with the internet using a single public (routable) IP address.
To understand why this is necessary, you need to understand the difference between private and public IP addresses.
Private IP address ranges (RFC 1918)
RFC 1918 defines three blocks of IPv4 address space as "private." These addresses are not routable on the public internet: no router on the internet's backbone will forward packets whose destination is a private address. They exist only inside private networks.
| Range | CIDR Block | Total Addresses | Typical Use |
|---|---|---|---|
| 10.0.0.0 to 10.255.255.255 | 10.0.0.0/8 | 16,777,216 | Large corporate networks, cloud provider internal networks, Docker/Kubernetes |
| 172.16.0.0 to 172.31.255.255 | 172.16.0.0/12 | 1,048,576 | Medium business networks, Docker bridge networks |
| 192.168.0.0 to 192.168.255.255 | 192.168.0.0/16 | 65,536 | Home networks (most routers assign 192.168.1.x or 192.168.0.x) |
Every device on your home network has a private IP address (typically 192.168.x.x). Your laptop, phone, smart TV, and Raspberry Pi all have addresses in this range that are invisible and meaningless to anything on the public internet. When any of these devices needs to communicate with a server on the internet, NAT makes it possible.
How NAT works: PAT (Port Address Translation)
The most common type of NAT used in home routers is PAT (Port Address Translation), also called NAT overload or NAPT. It allows multiple private IP addresses to share a single public IP address by distinguishing each connection using port numbers. Here is what happens step by step when your laptop (192.168.1.50) loads a website:
Your device sends a request
Your laptop sends a TCP packet to the web server at 93.184.216.34 (example.com) port 80. The packet's source address is your private IP: 192.168.1.50:54321 (a randomly chosen source port). The destination is 93.184.216.34:80.
Your router intercepts and translates the packet
The packet reaches your router. The router sees that the source address (192.168.1.50) is a private address that cannot be routed on the internet. It replaces the source IP and port in the packet header with its own public IP and a new port: 203.0.113.1:41234. The packet is now valid for internet routing.
The router records the mapping in the NAT table
The router stores this translation in its NAT table:
Private: 192.168.1.50:54321 → Public: 203.0.113.1:41234 → Destination: 93.184.216.34:80
The web server responds to the router's public IP
The web server sends a response to 203.0.113.1:41234 (your router's public IP). It has no knowledge that a device at 192.168.1.50 exists.
The router looks up the NAT table and forwards the response
The router receives the response packet. It checks the NAT table, finds the entry for port 41234, translates the destination address back to 192.168.1.50:54321, and delivers the packet to your laptop. Your laptop receives the web page as if it connected directly.
Multiple devices can use the internet simultaneously because the router assigns different public-side port numbers to each device's connections. The NAT table tracks all active connections and routes return traffic to the correct device. When a connection ends, its entry is removed from the table.
Why Inbound Connections Fail Through NAT
NAT works perfectly for outbound connections (your devices reaching out to the internet) because the connection is initiated from inside the network. The router creates a NAT table entry when the connection starts, and uses that entry to route return traffic back.
The problem with inbound connections (someone on the internet trying to reach your home server) is that there is no NAT table entry. The external device sends a packet to your router's public IP address. The router receives the packet and looks in its NAT table. There is no entry for this packet because no outbound connection was made first. The router does not know which internal device this packet is intended for. It drops the packet.
The fundamental asymmetry of NAT
NAT creates a one-way door. Connections originating from inside (your devices browsing the internet) work perfectly. Connections originating from outside (someone trying to reach your home server) are blocked by default because the router has no entry in its NAT table for unsolicited inbound packets.
Port forwarding is the manual solution to this problem: you explicitly tell the router "when a packet arrives on port 80, forward it to 192.168.1.100 port 80, even without a prior NAT table entry." This creates a permanent, pre-configured path for inbound traffic to a specific device.
Port Forwarding: The Traditional Solution
Port forwarding (also called Destination NAT or inbound NAT) is a router configuration that pre-maps an external port on the router's public IP to an internal device and port. When configured, inbound traffic matching that port is forwarded to the designated device without requiring a prior outbound connection.
| Service | External Port | Internal IP | Internal Port | Protocol |
|---|---|---|---|---|
| Web server (HTTP) | 80 | 192.168.1.100 | 80 | TCP |
| Web server (HTTPS) | 443 | 192.168.1.100 | 443 | TCP |
| SSH | 22 | 192.168.1.200 | 22 | TCP |
| Nextcloud | 8080 | 192.168.1.150 | 8080 | TCP |
| WireGuard VPN | 51820 | 192.168.1.100 | 51820 | UDP |
| Minecraft Java | 25565 | 192.168.1.100 | 25565 | TCP |
With port forwarding configured and a static (or DDNS-tracked) public IP, home servers are accessible from the internet. This worked reliably for most home users for two decades. Then CGNAT arrived.
What Is CGNAT (Carrier Grade NAT)?
CGNAT (Carrier Grade NAT), also known as Large Scale NAT (LSN), is NAT implemented at the ISP level rather than at the home router level. Instead of giving each customer a real public IPv4 address, the ISP assigns customers addresses from the RFC 6598 range (100.64.0.0/10) and performs address translation on its own network before traffic reaches the public internet.
The result is NAT applied twice: once at the ISP's infrastructure (CGNAT) and once at your home router. This two-layer structure is called NAT444, because three separate IPv4 address spaces are involved:
RFC 6598: The Address Space Designed for CGNAT
In April 2012, the IETF published RFC 6598, which reserved the IPv4 block 100.64.0.0/10 (covering 100.64.0.0 through 100.127.255.255, a total of 4,194,304 addresses) specifically for CGNAT use. This range was created because ISPs were already using RFC 1918 addresses (10.x.x.x, 192.168.x.x) for their internal infrastructure, which caused address collisions when customers used the same RFC 1918 ranges in their home networks. The 100.64.0.0/10 range solves this: it does not overlap with RFC 1918 and is not routed on the public internet, so it can be used exclusively by ISPs as the addressing layer between their CGNAT devices and customer routers.
RFC 6598 specifically states that the 100.64.0.0/10 range must not appear in public DNS zone files, must not be forwarded by internet backbone routers, and must be filtered at ISP network boundaries. It is exclusively an ISP-internal address space.
An interesting footnote from the RFC: a /10 block was chosen because the RFC authors determined that this was the smallest prefix that would provide a unique address for every service point in the Greater Tokyo Area, the largest metropolitan area in the world, as a worst-case planning scenario.
How to Detect if You Are Behind CGNAT
There are two reliable methods to check whether your ISP uses CGNAT for your connection.
Method 1: Compare your router's WAN IP with your public IP
Find your router's WAN IP address
Log into your router's admin panel (typically at 192.168.1.1 or 192.168.0.1). Find the WAN or Internet status page. Note the IP address shown as your WAN/Internet IP. This is the IP your ISP assigned to your router's internet-facing interface.
Find your actual public IP address
From any device on your home network, open a browser and visit whatismyip.com or search "what is my IP." The address shown is the IP address that the internet sees for your traffic.
Compare the two addresses
If the router's WAN IP and your public IP are identical, you have a real public IP. Port forwarding can work for you. If the two addresses are different, you are behind CGNAT. The router's WAN IP is an ISP-internal address that is itself NATted to the public IP you see on whatismyip.com. Port forwarding on your router does nothing because you do not control the outer NAT layer.
Method 2: Check for RFC 6598 addresses
If your router's WAN IP falls within the range 100.64.0.0 to 100.127.255.255, this is the RFC 6598 CGNAT address space. This is a definitive indicator of CGNAT. You are behind your ISP's NAT device, and the address you have is not routable on the public internet under any circumstances.
You can also check via the command line from any device on your network:
# Linux / macOS: trace the route to a public address and look at the first hops:
traceroute 8.8.8.8
# Windows:
tracert 8.8.8.8
If any of the early hops (the first two or three) show addresses in the 100.64.0.0/10 range, you are behind CGNAT and those are your ISP's internal network hops.
Why CGNAT Makes Port Forwarding Impossible
Port forwarding requires that you control the device performing NAT between your internal server and the public internet. Under CGNAT, there are two NAT layers:
The CGNAT packet journey (inbound connection attempt)
An external user sends a packet to your public IP (e.g. 203.0.113.1) port 80, intending to reach your home web server.
The packet arrives at your ISP's CGNAT device. The CGNAT device looks in its NAT table for an entry for this public IP and port. There is no entry because no outbound connection was made from your home to create one. The CGNAT device drops the packet. The packet never reaches your home router.
Even if you have configured port forwarding on your home router pointing to your server at 192.168.1.100, the home router never sees the packet. The CGNAT device discards it before forwarding it to your home connection.
You cannot configure the ISP's CGNAT device. You do not have access to it. Even if you forward every port on your home router, the ISP's NAT layer sits between your router and the internet, and it blocks all unsolicited inbound connections by default. Your port forwarding rules are completely irrelevant because the traffic never reaches your router in the first place.
Under CGNAT, your ISP's public IP address is shared by multiple customers simultaneously. Each customer is distinguished by different port ranges. The ISP's CGNAT device tracks all concurrent connections from all customers and routes return traffic to the correct customer. A typical CGNAT configuration allocates a fixed port range per customer: for example, customer A uses ports 1024 to 17023 on the shared public IP, customer B uses ports 17024 to 33023, and so on. This sharing has side effects: if one customer under the same public IP gets that address blocked or blacklisted by a service (due to spam, abuse, or triggering rate limits), all customers sharing it are affected.
Complete IPv4 Address Space Reference for Home Server Operators
| Address Range | CIDR | Defined By | Purpose | Routable on Internet? |
|---|---|---|---|---|
| 10.0.0.0 to 10.255.255.255 | 10.0.0.0/8 | RFC 1918 | Private networks (large) | No |
| 172.16.0.0 to 172.31.255.255 | 172.16.0.0/12 | RFC 1918 | Private networks (medium) | No |
| 192.168.0.0 to 192.168.255.255 | 192.168.0.0/16 | RFC 1918 | Private networks (home/small office) | No |
| 100.64.0.0 to 100.127.255.255 | 100.64.0.0/10 | RFC 6598 | CGNAT / ISP shared address space | No (ISP-internal only) |
| 127.0.0.0 to 127.255.255.255 | 127.0.0.0/8 | RFC 1122 | Loopback (localhost = 127.0.0.1) | No |
| 169.254.0.0 to 169.254.255.255 | 169.254.0.0/16 | RFC 3927 | Link-local / APIPA (auto-assigned when DHCP fails) | No |
| Everything else | Various | IANA/RIRs | Public internet addresses | Yes |
Real-World Impact of CGNAT on Home Servers and Self-Hosting
CGNAT does not affect your ability to browse the internet, stream video, use social media, or do anything that involves your devices making outbound connections. Those all work normally because outbound connections create NAT table entries in both layers. The impact is entirely on inbound connections to services you want to host.
Solutions: How to Expose a Home Server Behind CGNAT
Despite being unable to receive unsolicited inbound connections, there are several ways to expose services running on your home network to the internet. All of them work around CGNAT by establishing an outbound connection first, which CGNAT allows, and then using that outbound connection to carry inbound traffic.
Option 1: Pay your ISP for a static public IP
- How it works: Your ISP assigns you a dedicated public IPv4 address that bypasses CGNAT. Port forwarding on your router works normally.
- Cost: Typically $5 to $20/month extra, varies by ISP and region.
- Availability: Not offered by all ISPs, especially mobile/LTE ISPs.
- Pros: Standard setup, no additional software, works with everything.
- Cons: Recurring cost, not available everywhere, still need DDNS if IP changes.
Option 2: VPS as a relay server
- How it works: Rent a cheap cloud server (VPS). Both your home machine and the VPS run WireGuard or a similar VPN. Your home machine initiates an outbound connection to the VPS. Traffic from the internet hits the VPS, which forwards it through the tunnel to your home machine.
- Cost: $4 to $10/month for a basic VPS.
- Pros: Full control, works for all protocols, stable permanent endpoint.
- Cons: Requires configuring and maintaining a VPS, traffic routes through the VPS (adds latency and bandwidth cost).
Option 3: Outbound tunnel service (Localtonet)
Tunnel services like Localtonet solve CGNAT by running software on your home machine that establishes a persistent outbound connection to a public endpoint server. The outbound connection is allowed by CGNAT (all outbound connections are). Traffic from the internet arrives at the public endpoint, travels back through the already-established outbound tunnel, and reaches your home server. Your home server never needs to receive an unsolicited inbound connection.
| Feature | Localtonet Tunnel | Port Forwarding (requires public IP) |
|---|---|---|
| Works behind CGNAT | Yes | No |
| Works without static IP | Yes | No (needs DDNS) |
| Requires router configuration | No | Yes |
| Supports HTTP/HTTPS | Yes | Yes |
| Supports TCP | Yes | Yes |
| Supports UDP (WireGuard, game servers) | Yes | Yes |
| Provides HTTPS automatically | Yes (for HTTP tunnels) | No (need to configure separately) |
| Works from shared/corporate network | Yes (outbound only needed) | Depends |
How Localtonet Bypasses CGNAT
The key insight is direction. CGNAT blocks unsolicited inbound connections but allows all outbound connections. Localtonet uses this asymmetry:
Your machine initiates an outbound connection
The Localtonet client on your machine connects outbound to Localtonet's relay servers. CGNAT allows this because it is an outbound connection initiated from inside your network. A persistent tunnel is established.
Localtonet provides you with a public endpoint
The Localtonet relay server exposes a public HTTPS URL (for HTTP tunnels) or a public UDP/TCP endpoint (for TCP/UDP tunnels). This endpoint is on Localtonet's servers which have real public IP addresses.
External traffic arrives at the public endpoint
A visitor opens your public URL, or an external service sends a webhook, or a WireGuard client connects to the UDP endpoint. The traffic arrives at Localtonet's servers.
Traffic travels back through the established tunnel
Localtonet's server forwards the traffic through the already-established outbound tunnel to your machine. Your local service (Nextcloud, WireGuard, Home Assistant, etc.) receives it and responds. The response travels back through the tunnel to the visitor. CGNAT never blocks any of this because it all travels through the outbound connection your machine already made.
Frequently Asked Questions
Is CGNAT my ISP's fault? Can I opt out?
CGNAT is a response to the exhaustion of IPv4 addresses, not negligence. ISPs cannot obtain new public IPv4 addresses at a reasonable cost because the global pool has been exhausted since 2011. CGNAT is the only scalable way to continue connecting new customers to the internet using IPv4. Whether you can opt out depends entirely on your ISP and region. Some ISPs offer a static public IP as a paid upgrade. Some offer it for free on request. Some do not offer it at all, particularly mobile and LTE internet providers who have very limited public IP pools. The long-term solution is IPv6 adoption, which gives every device a globally unique address and eliminates the need for NAT entirely, but IPv6 deployment is still incomplete worldwide in 2026.
What does 100.64.x.x mean on my router?
If your router's WAN IP address starts with 100.64, 100.65, 100.100, or any number from 100.64.0.0 to 100.127.255.255, your ISP has assigned you an address from the RFC 6598 CGNAT shared address space. This is a definitive indicator that you are behind CGNAT. This address is your ISP's internal address that connects your router to their CGNAT infrastructure. It is not routable on the public internet and cannot be used for port forwarding to expose home servers. The actual public IP your traffic appears to come from (visible on whatismyip.com) is different and is shared with other customers of your ISP.
Does CGNAT affect my internet speed or latency?
For typical internet use (browsing, streaming, gaming as a client), CGNAT adds negligible latency. The translation happens in hardware at the ISP's infrastructure and the additional processing time is measured in microseconds. Bandwidth is not affected. The main impact is on hosting: you cannot receive unsolicited inbound connections, which prevents traditional port forwarding. Some peer-to-peer applications (certain games, BitTorrent, WebRTC direct connections) may experience degraded performance or need STUN/TURN servers for NAT traversal, but this is unrelated to your download or upload speed for normal traffic.
Why does IPv6 solve the problem, and do I have it?
IPv6 uses 128-bit addresses instead of 32-bit, providing 340 undecillion unique addresses. This is enough to give every device on Earth its own globally unique, publicly routable address, eliminating the need for NAT entirely. With IPv6, your home server would have a real public IPv6 address, and you could receive inbound connections directly without port forwarding or tunnels. To check if you have IPv6 connectivity, visit test-ipv6.com. If it shows a valid IPv6 address and confirms connectivity, you can host services accessible via IPv6. However, many visitors still use IPv4-only connections, so IPv6-only hosting is not yet a complete solution.
If I am behind CGNAT, can I host anything at all from home?
Yes, with the right approach. CGNAT blocks unsolicited inbound connections but allows all outbound connections. Tunnel services like Localtonet use this asymmetry: your machine makes an outbound connection to a relay server, which then carries inbound traffic back through that established connection. This works for HTTP, HTTPS, TCP, and UDP (the last being important for WireGuard VPN and game servers). The hosting experience is functionally identical to having a public IP, except the public endpoint is on the tunnel provider's servers rather than your home IP.
What is the difference between NAT and a firewall?
NAT and firewalls are separate concepts that are often confused because home routers implement both. NAT translates IP addresses and ports between private and public address spaces. It does not have explicit allow or deny rules; it simply has no NAT table entry for unsolicited inbound packets, which causes them to be dropped as a side effect. A firewall is a separate layer that explicitly inspects packets and applies rules to allow or deny traffic based on source, destination, port, and protocol. The practical effect of NAT for home users is that it blocks unsolicited inbound connections, which looks like firewall behavior, but the mechanism is different. A separate firewall (which modern routers also include) may additionally block traffic that has been port-forwarded, which is why setting up a home server sometimes requires both configuring port forwarding and adjusting firewall rules.
Host Services from Home, Even Behind CGNAT
Localtonet's outbound tunnel bypasses CGNAT without port forwarding, a static IP, or any router configuration. Works with HTTP, HTTPS, TCP, and UDP. Run Nextcloud, WireGuard, Home Assistant, Vaultwarden, or any other service from your home network and make it publicly accessible. Free to start.
Get Your Free Tunnel →