Hosting a Server on Starlink, T-Mobile or 5G Home Internet

Starlink, T-Mobile Home Internet and Verizon 5G Home all put residential customers behind CGNAT, so port forwarding does nothing and there is no address to point a DNS record at. IPv6 is often available on exactly these connections, costs nothing, and solves it outright for some uses. Here is the two-minute check that settles it for your line, and what each answer means.

Check your own line — do not trust this page

Carrier policies change, differ by region, and differ between plans sold under the same brand. Anything written here about a specific provider can be out of date by the time you read it. The check below cannot be, because it asks your own connection.

On the machine you want to host from, compare two addresses. First, what your router thinks it has:

ip addr show on Linux, or the WAN or Status page of the router or gateway app.

Second, what the internet sees:

curl -4 https://ifconfig.me

If those two differ, you are behind CGNAT and no amount of port forwarding will help — your router is forwarding ports on an address that is not the one anybody can reach. The other tell is the router's WAN address falling inside 100.64.0.0/10, a range reserved for exactly this purpose, though carriers also use ordinary private ranges.

While you are there, check whether you have IPv6, because it changes the answer completely:

curl -6 https://ifconfig.me

If that returns an address, read the IPv6 section below before anything else.

What these three carriers have in common

Starlink, T-Mobile Home Internet and Verizon 5G Home are different technologies sold to the same customer, and they made the same architectural choice for the same reason. All three grew fast, in an era with no IPv4 addresses left to buy at sane prices, so all three put residential subscribers behind carrier-grade NAT and share one public address among many customers.

The consequence is identical in each case, and it is not a setting: there is no inbound path to buy, enable or configure. Your gateway holds an address that is not globally unique, so an unsolicited packet arriving at the carrier's edge has no way of knowing it was meant for you. Port forwarding on your own router is real and works — it just operates one layer below the one that is actually blocking you.

Some of these carriers have at various times offered a public or static address, usually on a business plan and usually at a price. That is the cleanest fix when it exists, and it is worth one phone call before you build anything. Ask for a public IPv4 address, not CGNAT — front-line support frequently hears "static IP" as a different, more expensive product.

Try IPv6 first, because it is free and these carriers usually have it

CGNAT exists because IPv4 ran out. IPv6 did not, so the carriers most likely to put you behind CGNAT are also the ones most likely to hand you genuine, globally routable IPv6 — often a whole prefix, with every device on your network getting a real address and no translation layer anywhere.

If curl -6 https://ifconfig.me returned an address, inbound IPv6 probably works today once you open your firewall for it. There is no port forwarding involved because there is no NAT involved.

The catch is entirely on the other end. Whoever connects to you must have IPv6 themselves. For something you use personally from a modern phone network, that is usually fine. For a public service, a game server with players on mixed connections, or a vendor's webhook sender, it is not — a meaningful share of the internet still cannot open an IPv6 connection, and you will never see the ones that silently failed. They will not report a bug; they will conclude your thing is broken.

So IPv6 is the right first answer for personal access and the wrong one for anything public-facing. Test it before you build on it, from a network that is not your own.

Three things that will not fix this

Port forwarding. Covered above. It is the first thing everyone tries and it cannot work, because the address it forwards on is shared.

Dynamic DNS. DDNS solves a different problem — an address that changes. It keeps a name pointed at whatever address you currently hold. Behind CGNAT the address you hold is not reachable in the first place, so DDNS will faithfully publish an address nobody can connect to.

Putting the gateway in bridge mode. On a connection with a real public address this hands it to your own router and is genuinely useful. Behind CGNAT it hands your router the same unreachable shared-range address the gateway had. Worth trying, because some equipment behaves differently than documented, but do not expect it.

What works when IPv6 is not enough

Every remaining option uses the same trick, because it is the only one available: your machine makes an outbound connection to something that does have a public address, and holds it open. Your side initiated it, so both NAT layers have a mapping, and traffic can flow back down it. CGNAT never has to accept an unsolicited packet.

What the options differ on is what arrives at the far end.

A reverse tunnel service — Cloudflare Tunnel, Tailscale Funnel, ngrok — gives you a hostname on their domain, terminating on their infrastructure, usually shaped around HTTP. For a web service consumed by people, Cloudflare Tunnel is free and excellent and you should probably use it. For access to your own devices, Tailscale is free and better than a public address. Both are covered properly in their own comparisons.

Your own VPS plus WireGuard gives you a real address and arbitrary ports, for a few dollars a month plus the ongoing job of operating a second machine.

A leased routed address inverts it: instead of forwarding some ports from a server you rent, a network that owns address space assigns you one of its addresses, announces it, and routes everything for it down a tunnel to your hardware. What arrives at your machine is a whole address rather than a hostname or a port mapping. That is what we do.

Two wrinkles specific to these connections

Your address changes, sometimes often. On mobile and satellite links the shared public address can move between sessions, cell handovers or satellite re-associations. Anything that pins your identity to the address your carrier gave you will break. All the tunnel-based options are immune to this by construction, because your machine re-dials outward and the identity lives at the far end — but it is worth knowing why the DDNS answer fails twice over.

Idle connections get reaped. Carrier NAT tables are large but not infinite, and mappings for idle flows are dropped aggressively — sometimes within a minute or two, more aggressively than on wired connections. Any tunnel you rely on needs a keepalive, or it will appear to work and then quietly stop whenever the link goes quiet. WireGuard's PersistentKeepalive exists precisely for this; 25 seconds is the usual value and it is what our configurations ship with.

Where TunnelNet fits

We lease you a real, globally routable IPv4 address from our own block and route it to hardware you already own, over a WireGuard tunnel that dials out from your side. Because it dials out, CGNAT is bypassed by the same mechanism as every other option here — and because what we route is an address rather than a port mapping, what you get is a machine on the internet rather than a hostname pointing at one.

That is worth $10 a month if you need arbitrary ports, if the people connecting to you cannot be told to use a hostname, or if IPv6-only would silently lose you visitors. If none of those apply, one of the free options above is genuinely the better answer and we would rather you used it.

The CGNAT guide goes deeper on the mechanism and covers every option in more detail; plans and prices are one page over.