NAT at your edge is a design choice. NAT at your ISP's edge — carrier-grade NAT — is a constraint someone else chose for you, and it removes capabilities you may have built services around.
The symptoms arrive as a support ticket: "the camera system stopped being reachable from outside," or "our VPN endpoint's address changed again."
Two translations, one difference
| Your NAT | CGNAT | |
|---|---|---|
| Where | Your firewall | ISP's aggregation router |
| Address | Your public IP | Shared among many subscribers |
| Inbound | Port forwarding works | Usually impossible |
| Control | Yours | None |
| Logging | You have it | The ISP has it |
CGNAT uses the 100.64.0.0/10 range (RFC 6598) between the ISP and the subscriber. Your router may see
a 100.64.x.x address as its "WAN IP," which is the tell.
What stops working
- Port forwarding. There is no unique public address to forward to.
- Inbound VPN. A site-to-site tunnel to your edge cannot be initiated from outside.
- Hairpin NAT. The public name does not map to anything you control.
- GeoIP and reputation. Your traffic appears to come from the ISP's shared address, so location and reputation are wrong.
- Abuse attribution. If the ISP asks who did something, they have logs; you may not.
- Some games, peer-to-peer, and IoT devices that assume a public address.
The address can change without notice
CGNAT allocations are often dynamic. A service that works today may break after a maintenance window, with no configuration change on your side. If a vendor requires a stable public IP, CGNAT is disqualifying.
What still works
- Outbound browsing, which is most of a district's traffic.
- Outbound-initiated tunnels: your router can dial a VPN to a cloud or district hub, and the tunnel persists.
- DNS, mail submission, and anything client-initiated.
- Cloud services that do not require inbound connections.
The practical pattern is reverse the direction: instead of accepting connections, dial out and keep the tunnel open.
Worked example: the ISP moves the district to CGNAT
Before: static public /29, port forwards for the camera NVR, the door controller, and a vendor's
support tunnel.
After: WAN address 100.64.12.33, no inbound.
| Service | Before | After |
|---|---|---|
| Camera remote view | Port forward 8443 | Vendor cloud relay, or outbound tunnel |
| Door controller | Port forward 443 | Vendor cloud, or tunnel to a hub |
| Vendor support | Inbound VPN | Outbound reverse tunnel |
| Public website | Hosted externally | Unchanged |
Options, in order of preference:
- Buy a static public IP from the ISP (often available as an add-on).
- Use provider-independent addressing with BGP, if the ISP supports it.
- Move services to cloud or a hub site, with outbound-only connectivity.
- IPv6, if the ISP provides it — CGNAT is an IPv4 problem.
What breaks in production
- A vendor contract that assumes a public IP, discovered after the migration.
- Monitoring that pings the public address, which now belongs to someone else.
- Log correlation, because the source address you see is the ISP's.
- Hairpin NAT rules that point at an address the ISP now owns.
- Dynamic address changes breaking allowlists on the far end.
Checklist
- You know whether your WAN address is public, shared, or
100.64/10. - Every inbound service has an owner and a plan for CGNAT.
- Outbound-initiated alternatives exist for remote access.
- Monitoring uses a stable target, not a shared public address.
- Static IP or PI space is priced before it is needed.
- IPv6 availability has been checked with the ISP.
Next
The edge is also where traffic meets the bill. Continue with QoS Where It Counts.