Starlink Port Forwarding: Why CGNAT Blocks It, and What Works

If you are a Starlink owner trying to reach a camera, NAS, lab server, game host, or VPN from outside your house, you are usually past the easy setup stage and into network design. As a network-focused Starlink tester, my role is to separate the router settings that matter from the ones that cannot work on this access network. The objective is simple: get inbound access without weakening the whole LAN. The key result is also simple: direct IPv4 port forwarding is impossible on standard Starlink CGNAT, but four bypass paths work when matched to the job. The evolving decision is whether you need cheap personal access, public customer access, low latency, or business-grade support.

What CGNAT changes on Starlink

Carrier-grade NAT is a provider-level translation system that lets many subscribers share fewer public IPv4 addresses. The technical reason is address scarcity: IPv4 has about 4.3 billion addresses, far fewer than the number of phones, routers, cameras, satellites, and cloud workloads now online. The reserved carrier-sharing block is 100.64.0.0/10 in RFC 6598, which covers 100.64.0.0 through 100.127.255.255.

Port forwarding is a router rule that sends unsolicited inbound traffic on a public port to a private device. That rule only works when the router has the public address or when the upstream provider forwards the same port to you. Starlink Residential does neither. Starlink's own Finnish transparency disclosure lists Residential IPv4 address type as CGNAT and IPv6 as available, while Local Priority is listed as CGNAT, public IP optional. It also lists typical Residential speeds at 50-150 Mbps down and 5-25 Mbps up, and Priority at 50-220 Mbps down and 10-30 Mbps up.

IPv6 is a newer internet addressing system that can give devices globally routable addresses without IPv4 NAT. That sounds like the perfect answer, and sometimes it is. But IPv6 changes the security model: if a device is globally reachable, the firewall becomes the control point. A sloppy IPv6 rule can expose more than one camera or NAS. Read the basics of carrier-grade NAT and IPv6 before treating it as a checkbox.

“If your Starlink WAN address starts with 100.64 through 100.127, the failure is not your Netgear, UniFi, or pfSense rule. The packet dies one NAT layer earlier, before your router ever sees TCP port 443, 32400, or 51820.”— Hommer Zhao, SatSpeedCheck Network Analyst

Why the Starlink router setting is not enough

A third-party router is still useful on Starlink. It gives you proper firewall rules, VLANs, WireGuard, dynamic DNS, DNS overrides, better Wi-Fi, and logs. But it cannot create a public IPv4 route through Starlink's carrier NAT. Putting the Starlink router in bypass mode and connecting a UniFi Dream Machine, Firewalla, MikroTik, Asus, or pfSense box improves LAN control; it does not change the upstream addressing model.

The diagnostic is quick. Open your router's WAN status page. If it shows a 100.64.x.x address, then visit a public IP checker from a laptop on the same network. If the two addresses differ, you are behind CGNAT. You can still create a local port forward from WAN to LAN, but Starlink's upstream gateway is the real public edge. It has no per-customer rule sending port 8123 to your Home Assistant box.

This is why generic advice like “enable UPnP,” “reserve a static DHCP lease,” or “open port 80” only solves half the path. Those steps help on cable or fiber where your router owns the public address. For Starlink Residential, the correct mental model is outbound-first: your device must initiate a connection to a reachable public endpoint, and remote users come back through that established tunnel.

The four bypass paths that actually work

Choose the bypass based on who needs access. A private admin connecting from a laptop has different needs than a public Minecraft server or a business firewall peer. The table below assumes standard Starlink Residential or Roam service unless the plan column says otherwise.

1. Cloud tunnel for web services

A cloud tunnel is the cleanest answer for web dashboards. Cloudflare Tunnel, ngrok, and similar services run a small connector on your LAN. That connector opens an outbound encrypted session to the provider. The provider gives you a public hostname, and inbound visitors hit the provider first. Since the Starlink side initiated the tunnel, CGNAT does not block it.

Use this for Home Assistant on port 8123, a Grafana dashboard, an admin portal, a small web app, or a status page. Put authentication in front of it. Do not expose an unauthenticated NAS admin panel just because the tunnel made it easy. For cameras, prefer a vendor relay or VPN unless you are publishing a read-only web view behind access controls.

Expect excellent reliability and modest latency. A web dashboard does not care if the path adds 20 ms. Video feeds care more about upload speed, so test your real uplink with the Starlink speed test before promising a 1080p stream to several users.

2. Mesh VPN for private access

A mesh VPN is the safest default for private remote access. Tailscale, ZeroTier, WireGuard, and similar tools create a private overlay network between your phone, laptop, server, and sometimes your router. The Starlink device dials out; your laptop dials out; the control plane helps them find each other. When direct peer-to-peer cannot happen, traffic relays through a public node.

This is the right pattern for SSH, Remote Desktop, NAS files, Proxmox, pfSense management, and Home Assistant when only you or your family need access. It is also better than opening ports because the service is invisible to random internet scans. The tradeoff is client management: every device needs an app, a WireGuard profile, or a subnet route.

“For a home lab, I would rather see one WireGuard subnet route than five exposed TCP ports. One 10.0.0.0/24 route with MFA beats public 22, 80, 443, 8123, and 32400 every time.”— Hommer Zhao, SatSpeedCheck Network Analyst

3. VPS reverse tunnel for raw TCP or UDP

A VPS reverse tunnel is the flexible engineer option. Rent a $5 to $15/month virtual server with a public IPv4 address in the closest metro. Run WireGuard, FRP, rathole, boringproxy, or SSH reverse tunnels between your Starlink LAN and the VPS. Public users connect to the VPS address and port; the VPS forwards traffic through the tunnel to the device at home.

This is the most realistic way to host a small game server, expose SSH to a narrow allowlist, run a custom TCP service, or support UDP protocols that cloud web tunnels do not handle well. Keep the VPS geographically close. A Seattle relay for a Washington cabin may add 12 ms. A New York relay for the same cabin may add 70 ms and make games feel broken even when Starlink itself is fine.

Measure the baseline before blaming CGNAT. Run the speed test at idle, then compare it with the tunnel path. If your local Starlink is already struggling at 8pm, read why Starlink gets slow before adding another relay to the path.

4. IPv6 or Priority public IP for direct reachability

IPv6 is the direct, no-relay option when both ends support it. If your Starlink router or third-party router receives an IPv6 prefix, you can allow inbound IPv6 to one specific host and port. Do this with explicit firewall rules, not broad allow-all settings. A good rule names one device, one protocol, one port, and one source group whenever possible.

Priority public IP is the paid version of direct reachability. Starlink's own transparency PDF describes Local Priority and Global Priority as having optional public IP. That is the route to pick for business firewalls, NVRs that require inbound IPv4, customer-facing services, or site-to-site VPNs that must work with legacy peers. It also pairs naturally with the plan decisions covered in Starlink data caps explained and which Starlink plan fits you.

Do not buy Priority only because a camera app says “port forward required.” Many camera systems have cloud relay, P2P relay, or VPN support that is cheaper than a plan upgrade. Buy Priority when the remote peer cannot install VPN software, must reach a normal IPv4 address, or belongs to a business process where a $100/month delta is cheaper than a failed connection.

Use-case recommendations

Home Assistant: use a cloud tunnel with strong identity controls or a mesh VPN. Avoid raw public 8123 unless you also manage updates, TLS, lockouts, and MFA. Most households should never expose automation controls to the open internet.

Plex or Jellyfin: mesh VPN works best for private viewers. For friends and family outside your devices, a VPS tunnel can work, but upload speed is the cap. A 20 Mbps Starlink uplink can handle one high-quality 1080p stream or several transcoded lower-bitrate streams, not a crowd.

Security cameras: vendor cloud relay or VPN is safer than forwarding RTSP. Four 1080p cameras at 4 Mbps each consume 16 Mbps before overhead, which can saturate a busy Residential uplink. For camera placement and weather reliability, pair this with the Starlink installation guide and obstruction checks.

Game servers: use a geographically close VPS tunnel or a game host. Starlink can play games well, as covered in Starlink for gaming, but hosting adds upload and relay sensitivity. Keep the player count low and test during the 7-11pm peak window.

Business VPN: use Priority public IP or a site-to-site tunnel initiated from the Starlink side. For firewall peers that require static allowlists, put a cloud firewall or VPS with fixed IP in the middle unless Starlink has explicitly provisioned the addressing your partner requires.

“The break-even is not technical; it is operational. If one truck roll or one failed VPN shift costs $250, a Priority public IP can make sense. If it is just a home NAS, a $6 VPS tunnel is the better engineering choice.”— Hommer Zhao, SatSpeedCheck Network Analyst

Setup checklist before you expose anything

First, confirm the address model. Record your router WAN IP, public IP checker result, Starlink plan, router model, and whether IPv6 is present. Second, define the smallest possible access need: one user, one service, one port, one protocol. Third, choose the path: mesh VPN for private access, cloud tunnel for web apps, VPS tunnel for raw ports, IPv6 for modern direct access, Priority public IP for business IPv4.

Fourth, lock down authentication. Use MFA where supported, disable password SSH in favor of keys, avoid default camera passwords, and limit source IP ranges when you can. Fifth, test from a phone on cellular, not from Wi-Fi. Sixth, measure latency and throughput. A tunnel that works technically can still feel bad if it cuts your 20 Mbps upload to 5 Mbps or adds 80 ms to a game server.

Finally, keep a rollback plan. If you change firewall rules on a remote cabin Starlink, leave an outbound management path that cannot be locked out by one bad inbound rule. A mesh VPN installed on the router plus a local admin laptop profile is often enough. For off-grid sites, check the Starlink power sizer because a router, switch, PoE camera, and mini PC can add 15-40 watts beyond the dish.

FAQ