Starlink

Starlink CGNAT explained: why remote access breaks — and the fix

Starlink has been transformative for remote sites — genuinely usable broadband where there was nothing but a flaky 4G signal. But there's a catch that catches almost everyone out the first time they try to reach their site remotely: CGNAT. If your VPN won't connect, your cameras aren't reachable, or your port forwards simply don't work, this is almost always why.

What is CGNAT?

CGNAT — Carrier-Grade NAT — is how Starlink (and most 4G/5G networks) conserve the world's dwindling supply of IPv4 addresses. Instead of giving your dish its own public IP address, Starlink puts you behind a shared address along with lots of other customers. Your equipment gets a private address; the carrier translates it on the way out.

For outbound browsing this is invisible — web pages, cloud dashboards and email all work fine. The problem is inbound connections: anything that needs to reach into your site from the outside.

Why it breaks remote access

Because your site doesn't have its own public address, there's nowhere on the internet that points back to it. That means:

  • Port forwarding doesn't work — there's no public IP to forward from.
  • Site-to-site and inbound VPNs fail — the far end has no fixed address to dial.
  • Remote CCTV and NVR access won't connect directly; you're reliant on third-party relay/cloud services that add cost, latency and another point of failure.
  • SCADA, PLCs and remote engineering access can't be reached from head office.
  • Your public IP can also change without warning, so even workarounds that rely on the current address break.

The workarounds — and why they fall short

People try a few things. Dynamic DNS doesn't help, because behind CGNAT there's no public IP to map a hostname to. Cloud relay apps (the "P2P" access built into many camera systems) can work, but they're outside your control, often throttled, and a poor fit for anything critical or multi-site. Third-party mesh VPNs help for device-to-device access but add another dependency to manage and monitor.

The proper fix: a static public IP

The clean solution is to give your Starlink site a fixed, public IPv4 address that lives outside CGNAT. In practice we do this by routing the site's traffic through a managed router and a secure tunnel to a public IP we control, so your site behaves exactly like it has its own dedicated line:

  • Inbound VPNs, port forwarding and remote access all work normally.
  • The address never changes, so firewall rules and DNS stay valid.
  • CCTV, NVRs, SCADA and remote engineering are reachable directly and securely.
  • It works over Starlink, 4G/5G or a mix — and carries across to a backup bearer on failover.

We cover exactly how this works, and what's involved, on our Static IP for Starlink page.

Do you actually need one?

If everything on your site only ever reaches out — a laptop, a cloud dashboard, general browsing — you can live with CGNAT. The moment you need something to reach in (cameras, VPN, SCADA, remote support), a static IP is the difference between "it works" and "it doesn't". For most operational and renewable-energy sites, that's not optional.

Pair it with multi-bearer failover so the same fixed address rides across to a backup connection if Starlink drops, and you have a site that's genuinely reachable, 24/7.

Rural Connectivity Group

Stuck behind CGNAT?

We give Starlink and 4G/5G sites a fixed public IP, so remote access just works. Let's sort yours.