How to Access IP Cameras Behind CGNAT (Carrier-Grade NAT)

You've set up port forwarding on your router for RTSP port 554, tested it from your phone's mobile data, and your camera is completely unreachable. You haven't made a mistake — your ISP has. You're behind Carrier-Grade NAT (CGNAT), and port forwarding simply does not work at all in this situation.

CGNAT affects a significant and growing proportion of residential internet connections, particularly on fixed wireless, cable, and mobile broadband services where IPv4 addresses are scarce. If you're trying to access RTSP cameras remotely and port forwarding is failing silently, CGNAT is the most common culprit.

This guide explains exactly what CGNAT is, how to detect it, and which solutions actually work for remote camera access when you're behind it.

What Is CGNAT and Why Does It Break Port Forwarding?

The internet runs on IPv4 addresses, of which there are approximately 4.3 billion. That pool ran out years ago. ISPs worldwide have been using Network Address Translation (NAT) for decades to let multiple devices share a single IP address — your home router does this every time it maps your multiple devices to one public IP.

Carrier-Grade NAT adds another layer of this same translation, but at the ISP level. Instead of your router getting a true public IPv4 address, your router gets a private address in the 100.64.0.0/10 range (RFC 6598 — specifically 100.64.0.0 through 100.127.255.255). The ISP's own NAT device then maps thousands of customers' private addresses to a smaller pool of real public IP addresses.

The result is a double-NAT architecture:

Your Camera (192.168.1.100)
    ↓ LAN
Your Router (WAN: 100.72.14.88)   ← RFC 6598 private address
    ↓ ISP network
ISP CGNAT Device (203.0.113.45)   ← True public IP, shared by ~500 customers
    ↓ Internet

Port forwarding on your router creates a rule that maps inbound connections on a port to your camera's LAN IP. But your router's WAN address (100.72.14.88 in the example above) is not reachable from the internet — it is a private address only visible inside the ISP's network. Traffic from the internet arrives at the ISP's CGNAT device (203.0.113.45), which has no forwarding rule pointing to your router, so the connection is silently dropped.

Even if you configured your router correctly, you cannot create a port forwarding rule on the ISP's CGNAT equipment — you don't have access to it. Port forwarding is fundamentally broken in this topology.

How to Detect If You're Behind CGNAT

Method 1: Compare Router WAN IP vs. Public IP

This is the most reliable detection method:

1. Log into your router's admin panel (usually 192.168.1.1 or 192.168.0.1)
2. Find the WAN or Internet status page and note the WAN IP address shown
3. From any device on your network, visit whatismyip.com and note the IP shown
4. If the two addresses are different, you are behind CGNAT. Your router's WAN IP is a private address assigned by your ISP, not a real public IP.

Method 2: Check the WAN IP Range

If your router's WAN IP falls in the range 100.64.0.0 – 100.127.255.255, you are definitively behind RFC 6598 CGNAT. You can check this quickly:

# On Linux/macOS — check your router's WAN IP via traceroute
# The first hop after your gateway is often the CGNAT device
traceroute whatismyip.com

# On Windows
tracert whatismyip.com

If you see multiple hops with private IP addresses (10.x.x.x, 172.16.x.x, or 100.64.x.x) before reaching a public IP, those intermediate addresses are inside the ISP's CGNAT infrastructure.

Method 3: Try Port Forwarding and Test

Set up a port forward on your router and test it from an external connection (mobile data, not the same network). If the port is unreachable even though the forwarding rule is configured correctly and the target device is running, CGNAT is almost certainly the cause.

Solution 1: Cloud Relay — Works Perfectly Behind CGNAT

A cloud relay is the only solution that works transparently behind CGNAT with no additional complexity. The reason is architectural: cloud relay agents make outbound connections only.

CGNAT has no effect on outbound traffic. Your router can freely open outbound TCP connections to any public IP — that is how your browser loads websites, how your devices receive software updates, and how every other internet service works. CGNAT only prevents the internet from initiating connections to you. A cloud relay exploits this asymmetry:

TheRelay Agent (your LAN machine)
    → Outbound connection to cloud server (port 443)
    → Stream tunneled through that outbound connection
    → Cloud exposes stable endpoint accessible from anywhere

No inbound connections required. CGNAT is completely irrelevant.

Setting Up TheRelay Behind CGNAT

The setup is identical regardless of whether you're behind CGNAT, a standard NAT, or a direct public IP. CGNAT doesn't change anything:

1. Create an account at app.therelay.net
2. Install the TheRelay agent on any macOS, Windows or Linux machine on your LAN that can reach the cameras
3. Add your camera's RTSP URL in the dashboard:

   rtsp://admin:password@192.168.1.100:554/stream

4. TheRelay issues a stable cloud endpoint — WebRTC, RTSP, HLS, RTMP, or SRT — accessible from anywhere in the world
5. Protect the endpoint with a token generated in the dashboard

The agent machine needs standard outbound internet access on port 443. No router configuration, no ISP coordination, no firewall changes. CGNAT is a complete non-issue.

Solution 2: VPN with a Public Exit Node

A VPN with a public exit node effectively gives your LAN machine a public IP address by routing its traffic through a cloud server you control. There are two approaches:

Self-Hosted WireGuard VPN

You rent a small cloud VPS (DigitalOcean, Linode, Hetzner — from $4-6/month), install WireGuard on it, and configure your LAN machine as a WireGuard peer. The VPS has a public IP. You then either:

• Port-forward on the VPS and route that port through the WireGuard tunnel to your camera, or
• Use SSH reverse tunneling from your LAN machine to the VPS

This works because the VPS has a genuine public IP — there is no CGNAT above it. The tunnel is outbound from your LAN machine to the VPS, bypassing CGNAT. Inbound connections to the VPS's public IP are then forwarded through the tunnel to your camera.

# On your LAN machine — persistent WireGuard peer config
# /etc/wireguard/wg0.conf

[Interface]
PrivateKey = <your-private-key>
Address = 10.0.0.2/24

[Peer]
PublicKey = <vps-public-key>
Endpoint = <vps-public-ip>:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

This is a viable solution but requires Linux expertise, ongoing VPS maintenance, and manual security hardening. It does not give you token-based access control, protocol conversion (WebRTC, HLS), or a management dashboard.

Tailscale / ZeroTier Mesh VPN

Mesh VPN tools like Tailscale and ZeroTier handle NAT traversal automatically using STUN/TURN techniques. They make outbound connections that CGNAT passes freely, then negotiate a path for peer-to-peer traffic. Behind strict CGNAT, direct peer-to-peer paths sometimes fail and traffic routes via relay servers operated by the VPN provider.

This approach works but requires installing the VPN client on every device that needs camera access — not practical for sharing streams with third-party applications or cloud services.

Solution 3: IPv6 — If Your ISP Supports It

IPv6 has enough addresses (approximately 3.4 × 10³⁸) that CGNAT is not needed. If your ISP provides IPv6 connectivity, your devices may have globally routable IPv6 addresses that can be reached directly from the internet.

To check if your camera or router has an IPv6 address:

# Linux: check for a global IPv6 address (not link-local fe80::)
ip -6 addr show | grep "scope global"

# If your camera has a global IPv6 address, you can access it as:
rtsp://[2001:db8::1]:554/stream

The practical limitations are significant:

• Most consumer IP cameras do not support IPv6 at all
• Your ISP, router, and camera must all support IPv6
• IPv6 firewall rules must be configured correctly (global addresses are firewalled by default on most routers)
• Your access clients must also have IPv6 connectivity
• Even with a global IPv6 address, the camera is fully exposed to the internet — all the CVE risks from port forwarding apply equally

IPv6 is a theoretical path but impractical for most camera deployments in the real world.

Solution 4: Dedicated Mobile Data Connection

A cellular/mobile data connection (4G/5G) typically provides a real public IP address — most mobile carriers have not deployed CGNAT at scale, though this is changing. You can connect a dedicated mobile router or USB modem to the machine running the camera agent, and use that connection specifically for the agent's outbound tunnel.

This is a niche but valid approach for remote installations where wired internet is only available via a CGNAT ISP, but cellular coverage is available. The camera still uses the main LAN connection; only the agent's cloud tunnel uses the mobile data.

Solution Comparison

Frequently Asked Questions

How do I know if I'm behind CGNAT?

Compare your router's WAN IP address (found in your router admin panel under the WAN or Internet status section) with your apparent public IP as shown by whatismyip.com. If the two addresses are different, you are behind CGNAT. A CGNAT address from your router's perspective will typically fall in the 100.64.0.0/10 range (100.64.x.x through 100.127.x.x) as defined by RFC 6598, though some ISPs use other private ranges. You can also run a traceroute and look for multiple hops with RFC 1918 or RFC 6598 addresses before the route reaches a public IP.

Does Tailscale work with CGNAT?

Yes. Tailscale uses a combination of direct peer-to-peer connections and DERP relay servers for situations where direct paths are blocked. Because Tailscale initiates only outbound connections, CGNAT does not prevent it from working. However, Tailscale requires installation on every device that needs access to the camera. It is not suitable for sharing streams with external applications, cloud services, or third parties who shouldn't need to install a VPN client.

Can I request a public IP from my ISP?

Some ISPs will assign a dedicated public IPv4 address on request, sometimes for a small monthly surcharge and sometimes at no cost on business-tier plans. Whether this is available depends entirely on your ISP and your location. If you do obtain a public IP, port forwarding becomes technically feasible — but the security risks of exposing your camera's RTSP daemon to the internet remain unchanged. A cloud relay is a safer solution regardless of whether you have a dedicated public IP.

Does CGNAT affect all my internet traffic?

CGNAT only affects inbound connections to your IP address. All outbound traffic — web browsing, video streaming, sending email, software updates — works normally because those connections originate from your devices. CGNAT only prevents external parties from initiating connections to your public IP address. This is precisely why cloud relay services work so well behind CGNAT: the relay agent makes outbound connections to the cloud server, which CGNAT passes without restriction. The camera stream is then tunneled through that outbound connection to the cloud, bypassing the CGNAT limitation entirely.