Starlink CGNAT vs a Homelab: When Inbound Ports Are the Product

Starlink will sell you a dish, a fat pipe, and a WAN address that is not yours. Carrier-grade NAT is not a footnote. It is the product constraint that decides whether your homelab is a client or a server. If the thing you built needs the internet to call you — a game box, a mail port, a camera NVR you refuse to put on someone else’s cloud, a WireGuard listener on 51820/udp — CGNAT is not an inconvenience. It is a closed door with a cheerful download speed behind it.

I moved a rack to a site that only had Starlink. I had already practiced the overlay story: Tailscale, a cheap VPS, Cloudflare Tunnel. I had not practiced the grief of discovering that “just forward 443” was a sentence from a previous decade. The dish was fine. The lab was fine. The public IPv4 was someone else’s, shared, and not accepting SYN to my house.

What CGNAT actually means on the dish

Your router’s WAN IP is in a shared range. Often it looks like CGNAT on purpose: 100.64.0.0/10, or a private-looking address that is not your LAN. Port forwards on the Starlink router, or on your own router in bypass, do not create a mapping the public internet can use. There is another NAT in front, owned by the operator, shared with other customers. UPnP will happily map a port to nowhere useful. You will test from your phone on the same Wi-Fi and call it a success. You will test from a VPS and get silence.

That last test is the only one that counts. Hairpin and “I used my phone on LTE” are different stories. LTE can be CGNAT too. Use a host that has a real address and is not your dish.

IPv6 is the other path Starlink sometimes gives you. If you have a delegated prefix and your lab speaks v6, inbound can work without buying a v4. Firewalls still matter. A wide-open v6 is not a personality. I treat v6 as a real WAN: allow lists, not hope. Many of the services people want — game consoles, random IoT apps, a friend’s Windows “connect to IP” dialog — still think v4 is the universe. v6 saves the services you control. It does not save the ones you do not.

Starlink has, in some markets, sold or enabled a public IPv4 option. Treat that as a SKU, not a rumor you rely on before you move the rack. If you do not have the toggle in the app, you do not have the address. Planning a homelab around a feature that exists in a forum screenshot from another country is how you unpack a UPS in a field and invent Tailscale at midnight.

When inbound ports are the product

Some labs are outbound-only and never notice CGNAT. Photos sync up. Backups push to a bucket. Home Assistant is used on the LAN or through an overlay. You are a client. Starlink is excellent at being a client.

Inbound ports are the product when the thing you offer is a listening socket the world must find without your software calling out first:

A dedicated game server that friends add by IP. They will not install Tailscale because you asked nicely. They will not type a Cloudflare hostname into a console that only wants IPv4 and a port.

Incoming SMTP or a self-hosted mail story that still believes in 25/465/587 from arbitrary peers. You can relay outbound through a provider. You cannot receive like a real MX if the world cannot open a connection to you. People who say “just use a VPS for mail” are not joking. They are describing the architecture CGNAT already chose.

Let’s Encrypt HTTP-01 against a box that is only on the dish, with no tunnel and no DNS-01. The CA has to reach :80. CGNAT says no. DNS-01 and a tunnel are the adults in the room. HTTP-01 on the house is nostalgia.

A “dumb” VPN concentrator: WireGuard or IPsec on a public UDP port, peers that are appliances, phones you do not manage, a site-to-site that cannot run an outbound client. Overlays that require an app on every peer are not a drop-in. If the peer is a camera that only speaks “connect to NVR IP,” you are in product-land, not hobby-land.

WebRTC or a self-hosted call stack without a TURN server you control on a public address. Symmetric NAT plus CGNAT is how calls work on Wi-Fi and die on the dish, or the other way around. TURN is the inbound port you outsourced.

If your weekend jobs are those jobs, Starlink residential CGNAT is the wrong WAN unless you add a second address somewhere else. The dish can still be the fat pipe. The listening socket has to live on a VPS, a colo, a friend’s fiber, or a paid public IP if you truly have one.

The overlays that feel like cheating and are not

Tailscale, Headscale, Netbird, a WireGuard outbound to a VPS: the lab dials out. The NAT you cannot control does not matter because you never needed a mapping. I run a subnet router on the Starlink site so the rest of my tailnet can reach LAN IPs. That is not inbound from the internet. That is inbound from people I already admitted. Different product. If “the product” was a public Minecraft port, this is not it. If “the product” was me SSHing home, this is exactly it.

Cloudflare Tunnel, a reverse SSH, frp, a cheap VPS with socat or a proper reverse proxy: same shape. The house initiates. The public name lives on someone else’s anycast or a $5 VM. You are renting the inbound port. Be honest about the dependency. When Cloudflare has a bad day, your “self-hosted” site is a client that cannot find its front door. I still use it. I do not pretend it is a port forward.

Bypass mode on the Starlink router plus your own firewall does not lift CGNAT. It lifts double NAT on your LAN. Do it for sane IPv6, for a real DHCP story, for not fighting their router’s hairpin. Do not do it because a blog said bypass equals public IP. Bypass plus CGNAT is still CGNAT with better logs.

What still leaks, what still dies

CGNAT does not hide you from the overlay operator or from the VPS. It hides you from unsolicited IPv4. Your outbound connections still have a source the far end sees — a shared egress. Abuse complaints can still land on a pool. Some services rate-limit CGNAT ranges as if they were a campus. I have had Git hosts and APIs get weirder on the dish than on fiber for that reason, not because the latency to the satellite was the only villain.

Latency is the other product. Even with a clean outbound VPN, RTT to a nearby VPS is not fiber. Game servers you host on the VPS and backhaul to the house are a bad topology. Host the sim on the VPS. Use the house for files and controllers. Do not trombone a tick loop through space.

IPv6 inbound that you forgot to firewall is a different outage: you become the product for scanners. I have seen people celebrate “Starlink gave me v6” and then find SMB on a NAS reachable from the world. CGNAT was accidentally their security model. Removing it on one protocol without a policy is how you learn iptables at 2 a.m.

A decision that is actually a purchase

If the site is Starlink-only and you need a public listener, buy the listener. A small VPS in a region you can stand, WireGuard to the house, proxy or DNAT on the VPS. Or pay Starlink for public IPv4 if the app offers it and you have measured that it is a real routable address, not another pool. Or keep the lab on fiber and use Starlink as backup WAN with outbound-only failover. I like the third option when I have a choice. Failover that cannot accept inbound is still useful for “the house can call out.” It is not useful for “the world can call in” unless the public socket lives elsewhere and the house is just origin.

Mail, games, and cameras are the three conversations I now have before anyone orders a dish for a “homelab.” Photos and HA and git-over-Tailscale are fine. A public origin on the kitchen rack is a second bill. If that bill offends you, the WAN is wrong, not the software.

How I would wire it tomorrow

Dish in bypass if I have a real router. Router does LAN, VLANs, outbound firewall, IPv6 with a default deny. No IPv4 forwards I will only lie to myself about. Tailscale subnet router on a Pi or an LXC that survives power blips. One VPS with a name I control, WireGuard to the router, Caddy or nginx for the two HTTPS things that must look public. Game servers on the VPS, not on the rack, unless the players are on the tailnet and I can say that out loud. Cameras stay on the VLAN; remote view is the overlay or a vendor I already accepted. Let’s Encrypt via DNS-01. No HTTP-01 aimed at the dish.

If a friend needs a port and will not run an app, the VPS publishes the port and the house is origin or the game is not at the house. I do not open a support ticket with Starlink titled “please forward 25565.” That ticket is a product mismatch.

The close

Starlink CGNAT is a fast client WAN. A homelab that sells inbound ports is a server. You can rent the server somewhere with an address, or you can change the product to outbound-only. What you cannot do is port-forward your way through a NAT you do not own and call it a weekend. The dish will keep downloading. The SYN will keep dying. The overlay was not a compromise. It was the topology the WAN already picked.