Starlink CGNAT and Port Forwarding: Remote Access Options

Starlink works well for everyday browsing, streaming and video calls, but remote access can be confusing. You may set up port forwarding correctly and still find that a camera, home server, game host or VPN cannot be reached from the internet.

The usual reason is carrier-grade network address translation (CGNAT). This guide explains how to identify it and choose a practical alternative without exposing more of your home network than necessary.

Plan features and IP addressing can vary by country and service tier. Check the current details shown in your Starlink account before changing plans or buying equipment.

The short answer

Most home users should not try to force traditional port forwarding through CGNAT. Choose the method that matches the job:

• Access your own devices privately: use a mesh VPN such as Tailscale.
• Publish a web dashboard or website: use an authenticated outbound tunnel such as Cloudflare Tunnel.
• Run a service that requires a directly reachable address: check whether your eligible Starlink plan offers a public IPv4 address, or use a virtual private server as a relay.

Do not place a camera, NAS administration page or router interface directly on the public internet.

What CGNAT means

A conventional home connection gives your router a public IPv4 address. When an outside device connects to that address, a port-forwarding rule can send the request to a device on your local network.

With CGNAT, several customers share an upstream public IPv4 address. Your Starlink router or third-party router is behind an additional translation layer operated by the provider. You control your own router, but you cannot create the matching inbound rule in that upstream layer.

That is why changing local port-forwarding settings alone does not solve the problem. Starlink's published service information identifies CGNAT as the IPv4 addressing method for at least some residential services, while public IPv4 availability depends on the service and market. Treat the plan details in your account as the final authority.

How to check whether you are behind CGNAT

Use a computer connected to your Starlink network.

1. Open your router's administration page and find its WAN, Internet or external IPv4 address.
2. In a browser, search for “what is my IP” and note the public IPv4 address reported by the website.
3. Compare the two addresses.

You are probably behind another NAT layer when the router's WAN address and the browser-reported address are different. A WAN address in the shared range 100.64.0.0 to 100.127.255.255 is a strong CGNAT indicator. Private ranges such as 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 also are not publicly routable.

If you use the Starlink router plus a second router without bypass mode, you may instead have ordinary double NAT inside your home. Put the Starlink router into bypass mode when appropriate, then repeat the comparison. Bypass mode can remove the extra local routing layer, but it does not remove provider-side CGNAT.

Why port forwarding appears correct but fails

A port checker can report “closed” for several reasons. Work through these checks before blaming CGNAT:

• Confirm the service is running and listening on the intended device and port.
• Give the device a DHCP reservation so its local address does not change.
• Check the device firewall as well as the router rule.
• Test from a genuinely external connection, such as mobile data with Wi-Fi disabled.
• Make sure a second router is not creating another NAT layer.
• Compare the WAN and public IPv4 addresses as described above.

A port will also appear closed if no application is listening, even when the network path is correct.

Option 1: Use a private mesh VPN

For reaching your own NAS, computer, printer, Home Assistant dashboard or remote desktop, a private mesh VPN is usually the simplest answer.

Tailscale, for example, creates an encrypted private network between authorised devices. Its NAT traversal can establish peer-to-peer connections through many firewalls; when a direct path is unavailable, its relay network can carry the traffic. Because the connection starts outbound, it can work without a public IPv4 address or a traditional port-forwarding rule.

A sensible setup is:

1. Install the client on the device or server at the Starlink location.
2. Install it on the phone or laptop you will use remotely.
3. Sign in to the same private network and approve only the devices you recognise.
4. Test access using the private VPN address while away from home.
5. Enable multifactor authentication and review device access periodically.

If a camera or printer cannot run the client, a supported always-on device can act as a subnet router. Follow the provider's current documentation and restrict the advertised routes to only the network ranges you need.

Option 2: Use an outbound application tunnel

If you need to publish a web application rather than join two private devices, an outbound tunnel can be a better fit.

Cloudflare Tunnel runs a connector inside your network. The connector establishes outbound-only connections to Cloudflare, so it does not need a publicly routable origin address or an inbound firewall opening. You can place an identity check in front of a dashboard or internal web tool.

This approach suits HTTP applications and selected remote-access workflows. It is not a universal replacement for every protocol, and a public hostname without access controls can still expose a poorly secured application. Use authentication, least-privilege policies and application updates.

Option 3: Check for a public IP plan feature

Some Starlink services or priority tiers may offer public IPv4 addressing in certain markets. Availability, terminology and pricing can change, so check the plan management area of your account or ask Starlink Support what your specific service address supports.

Before upgrading, confirm all of the following:

• The address is publicly routable, not merely a different CGNAT address.
• Inbound connections are permitted for your intended use.
• The address is static or dynamic, and whether dynamic DNS will be needed.
• Your router supports the required firewall and forwarding controls.
• The total plan cost makes sense compared with a tunnel or relay.

A public address does not make a service safe. Allow only required ports, keep software patched, use strong authentication and maintain backups.

What about IPv6?

IPv6 can provide globally routable addresses without IPv4 port translation, but it is not a drop-in promise of remote access. Starlink availability, prefix behaviour, router support and firewall controls can vary. The remote network also needs working IPv6.

Use IPv6 only when you understand the firewall policy on your router. Do not disable the firewall simply to make a service reachable. For most home users, a private mesh VPN remains easier to control.

A quick decision guide

Choose a private mesh VPN when access should be limited to you, your family or your team.

Choose an authenticated application tunnel when users need a browser-based service and you can protect it with identity-aware access.

Choose a public IP or hosted relay when the application requires arbitrary inbound protocols, cannot run a VPN client, or must accept connections from devices you do not manage.

Choose no remote exposure when the product has weak authentication, old firmware or no reliable update path.

Security checklist before remote access

• Change default passwords and enable multifactor authentication where available.
• Update the router, server, NAS and application.
• Expose the smallest possible service, not an entire management network.
• Keep router administration disabled from the public internet.
• Use encrypted protocols and avoid plain HTTP for credentials.
• Review connected devices and access logs.
• Test from outside the Starlink connection.
• Keep a recovery path in case a configuration change locks you out.

Troubleshooting your chosen method

If a mesh VPN connects through a relay and feels slow, check local Wi-Fi quality and whether UDP traffic is restricted. A direct connection is preferable, but a relay is an expected fallback.

If an outbound tunnel will not connect, confirm DNS works and that the host firewall allows the connector's required outbound traffic. Check the connector status and logs before changing the router.

If a public-address setup fails, repeat the WAN-versus-public-address comparison, confirm the service is listening locally, and test from a separate internet connection. Ask Starlink Support to confirm the address type attached to your plan.

Bottom line

CGNAT is not a fault, and it does not reduce normal outbound internet use. It changes how unsolicited inbound connections reach your network. For private remote access, start with a mesh VPN. For a web application, consider an authenticated outbound tunnel. Only pursue a public address and traditional port forwarding when the application truly requires them.

Further reading: Tailscale firewall and NAT traversal guidance, Cloudflare Tunnel documentation, and Starlink Support.