dispelledStarlink, CGNAT, and Why Port Forwarding May Not Work
A normal IPv4 port forward assumes the firewall owns an internet-reachable address. Starlink’s default IPv4 policy uses carrier-grade network address translation, or CGNAT, so many customers share upstream public addresses. Your router can forward packets that arrive at its WAN interface; it cannot create a path through NAT operated inside the provider’s network.
Recognize the extra translation boundary
Ordinary home NAT translates private addresses such as 192.168.1.20 to the router’s WAN address. CGNAT adds another translation under the provider’s control. Starlink documents addresses from the shared 100.64.0.0/10 range for its default IPv4 service. This range is reserved for service-provider shared address space: it is not a globally routable public address.
| Observation | Likely meaning |
|---|---|
Firewall WAN is in 100.64.0.0/10 | The connection is behind CGNAT. |
| Firewall WAN is RFC 1918 space | Another local router may be creating double NAT. |
| Firewall WAN differs from a reputable external address check | There is probably another NAT boundary upstream. |
| WAN has a public address but inbound tests fail | Check firewall rules, modem or router mode, provider policy, and whether the address changed. |
Record the WAN address shown by the firewall and compare it with the address observed by an external service. Do not publish either address in screenshots or support posts. A mismatch is useful evidence, but confirm the service plan and provider documentation before concluding that CGNAT is the only cause.
Bypass mode does not remove provider CGNAT
Putting the Starlink router into bypass mode can remove one local routing and Wi-Fi layer when a third-party firewall is used. It does not change the default IPv4 policy inside Starlink’s network. Likewise, placing a server in a consumer router’s “DMZ host” setting or enabling UPnP cannot create an inbound mapping through provider CGNAT.
Public IPv4 is plan-dependent and dynamic
Starlink documents a public IPv4 option for eligible service plans. Availability can vary by plan, account, and region, and Starlink does not describe it as a static address. If inbound IPv4 is required, verify the current account options and use a third-party router or firewall that can apply the required inbound policy. Dynamic DNS can track a changing public address, but it cannot make a CGNAT address reachable.
IPv6 changes the path, not the security requirement
Starlink documents native IPv6 and delegated prefix service, but actual availability and behavior can depend on region, account, service plan, equipment, router support, and current configuration. Verify the current Starlink documentation and the prefix actually received by the firewall rather than assuming IPv6 is active. Where a capable third-party router receives a globally routable delegated prefix, IPv6 can provide a separate path even while IPv4 remains behind CGNAT.
That path avoids IPv4 destination NAT, but it does not make a host safe to publish. Global reachability depends on the router’s inbound IPv6 policy as well as the host firewall; some routers block unsolicited inbound traffic by default. Publishing requires an intentionally narrow rule, host policy, and separate review of public AAAA records.
Prefix assignment, router advertisements, DHCPv6 prefix delegation, and address stability need deliberate configuration. Test from a genuinely external IPv6 connection. A service can be unreachable over IPv4 yet publicly reachable over IPv6, which is why both protocols belong in the exposure inventory.
Choose an alternative based on the audience
- Only your devices or invited users need access: continue with Tailscale for Private Homelab Access Behind CGNAT.
- A public HTTP or HTTPS site is required: continue with Cloudflare Tunnel for Publishing a Web Service Behind CGNAT.
- You have a reachable public WAN address: a narrow firewall rule and properly isolated server may remain the simplest design.