Hosting a game server from behind CGNAT

Port forwarding does nothing behind carrier-grade NAT, and the way most people discover this is three hours into a firewall configuration that was correct the whole time.

The symptom is specific: everything works on your local network, the server shows as online to you, and nobody outside can connect regardless of what you forward.

How to know in two minutes

Look at the WAN address your router reports and compare it to what a "what is my IP" service tells you. If they differ, there is another layer of network address translation between you and the internet, and you do not control it.

The router's WAN address will usually be in one of the private-ish ranges — 100.64.x.x is the specific one reserved for carrier-grade NAT, and seeing it is conclusive.

That check costs nothing and it is the first thing to do before touching any firewall rule, because if it comes back positive then every port-forwarding step is wasted effort.

Why forwarding cannot work

Your router forwards a port on its own WAN address. Behind CGNAT that address is shared with other subscribers and is not routable from the internet. The packet never reaches your router to be forwarded.

There is no configuration that fixes this on your side. It is not a setting you have missed.

The four ways out, in order of how well they work

Ask for a public IP. Many providers offer one, sometimes free, sometimes for a small monthly fee, sometimes only on business plans. This is the correct fix and it is worth asking before anything else — one phone call resolves the whole problem.

Rent a small box and host there. Moves the server somewhere with a routable address. This is what most people end up doing, and for anything with more than a handful of players it was the right answer anyway once the upload bandwidth arithmetic is done.

Tunnel through a relay. A cheap VPS with a public address, forwarding traffic to your home machine over a tunnel. The game server stays at home; the address the world sees belongs to the VPS.

This works and it has a real cost: every packet takes an extra hop, so latency rises by the round trip to the relay. If the relay is close to you and to your players it is barely noticeable; if it is not, it is worse than useless for a shooter.

IPv6. If your provider gives you real IPv6 and your players have it, the problem disappears: there is no NAT. In practice a meaningful share of players do not have working IPv6, so this works as an addition rather than a replacement.

What the tunnel actually costs

Worth being concrete, because it is presented as free and is not.

Bandwidth through the relay is bandwidth you pay for twice: once on your home connection and once on the VPS plan. A busy server can exceed a cheap VPS's monthly allowance, and the overage is the surprise.

There is also a second point of failure. The relay going down takes the server offline even though the machine is running perfectly at home: the kind of outage that is confusing to diagnose because everything you can see is fine, which is the shape of most invisible failures.

What still has to be right afterwards

Getting a routable address solves reachability and nothing else. Both ports still need forwarding (the game port and the query port) and forgetting the second produces a server that friends can join and that appears on no listing at all.

That is the same failure as before, wearing a different cause, and it is worth checking from outside rather than assuming: a query port that answers nothing looks identical to a server that is switched off.

The honest recommendation

If the server is for a handful of friends, ask your provider for a public address, and if they will not, tunnel.

If it is for anybody else, host it somewhere with a routable address from the start. The cost of a small box is genuinely low, and the home-hosting problems do not stop at CGNAT: upload bandwidth, the machine being needed for other things, and the connection going down while you are out are all still there.

The one thing not to do is spend an evening on firewall rules before checking the WAN address, which is the most common way this goes, and which is entirely avoidable by spending the first two minutes on the question that decides everything else.