NAT and CGNAT: why home game servers fail

NAT lets many devices share one public address by rewriting their outgoing traffic, and it works because every conversation starts from inside. A game server is the opposite: strangers start the conversation from outside. On a normal home connection you fix that with a port forward on your router. Behind carrier-grade NAT (CGNAT) you cannot, because your ISP has put a second NAT, which you do not control, in front of your router - your "public" address is shared with other customers, and no forward on your side can claim a port on it. If your router's WAN address starts with 100.64 to 100.127, that is you. The ways out are a public IPv4 address from the ISP, IPv6, a relay or tunnel, or a server that lives somewhere else.

This post explains why, in more depth than a checklist: how NAT behaves, what the NAT types consoles and launchers report actually mean, why "host and invite" works when a dedicated server does not, and which workaround fits which situation.

What NAT does to a connection#

Your router keeps a translation table. When your PC at 192.168.1.20 sends a UDP packet from port 50000 to a game server, the router rewrites the source to its public address and some port of its choosing, records the mapping, and sends it on. The reply comes back to that public port, the router finds the mapping, rewrites the destination back to 192.168.1.20:50000, and delivers it.

Two consequences matter for hosting:

• Inbound packets with no mapping are dropped. A player's first packet to your server arrives at the router's public address with nothing in the table. The router has no idea which machine it is for.
• Mappings expire. A UDP mapping lives only as long as traffic keeps it alive. Linux-based routers default to about 30 seconds for a one-off UDP flow and a few minutes for an established one; consumer routers vary. A game that goes quiet for longer than that loses its mapping and the next packet from the server is dropped.

A port forward is a permanent mapping you write by hand, which is why it fixes the first problem. Port forwarding vs hosted servers covers writing one properly.

The four ways a NAT can behave#

Not every NAT treats traffic the same way, and the differences decide whether two players behind NAT can reach each other directly. The old names (cone and symmetric) are still the ones people use; the formal terms in RFC 4787 describe two separate behaviours, mapping and filtering.

Most home routers behave like a port-restricted cone. Many CGNAT deployments and some corporate and mobile networks behave symmetrically, which is the worst case for peer-to-peer games.

What consoles and launchers mean by NAT type

Consoles simplify this into three grades.

These grades matter for player-hosted sessions, where one player's machine is the host. They matter much less for dedicated servers, because a player connecting to a server starts the conversation from inside their own network - outbound traffic that every NAT allows. A player on Strict NAT can join a dedicated server on a public address without any trouble. That one fact is the main networking argument for a dedicated server for a group that includes people on mobile broadband or student housing. What a dedicated game server is covers the others.

Carrier-grade NAT#

ISPs ran out of IPv4 addresses years ago. Carrier-grade NAT is how they stretch what they have left: the ISP puts a large NAT in its own network and gives each customer's router an address from a shared range instead of a public one. Many customers then leave the internet through the same public address.

The shared range is 100.64.0.0/10 - every address from 100.64.0.0 to 100.127.255.255 - set aside by RFC 6598 for exactly this. It is deliberately separate from the private ranges in homes so that a home network and the carrier network never clash.

This setup is sometimes called NAT444, because traffic crosses three address spaces: your private network, the carrier's shared range and the public internet. Your router's port forward is still there and still correct, but the packets never reach it - they are dropped at the carrier's NAT, which has no mapping and which you cannot configure.

Side effects you may already have noticed

• Shared reputation. Your public address is shared with other customers. If one of them is abusive, websites challenge everybody with captchas, and a game server that bans that address bans all of you.
• Port limits. A carrier NAT often hands each customer a block of ports rather than the whole range. Normal browsing never notices; software that opens thousands of connections occasionally does.
• The address you see is not yours. Your public IP as shown by a "what is my IP" site is the carrier NAT's address. Giving it to your friends to join your server achieves nothing.

How to tell

1. Read the WAN or internet address on your router's status page.
2. Look up your public address from a browser on the same connection.
3. If they differ, there is NAT in front of your router. If the router's address is in 100.64.0.0/10, it is CGNAT. If it is in 192.168.x.x or 10.x.x.x, it is more likely an ISP modem doing NAT inside your own house - double NAT, which you can fix yourself.

A traceroute from inside shows the same thing: a hop in the 100.64 range shortly after your router is the carrier NAT.

DS-Lite, the common variant

Many cable and fibre providers - including large ones in Germany - use Dual-Stack Lite. The connection gets real, public IPv6, while IPv4 is tunnelled to the ISP and shared through a carrier NAT. The router may not even show an IPv4 WAN address at all. The effect for a game host is the same as CGNAT for IPv4, with one useful difference: IPv6 inbound works, so a server reachable over IPv6 is possible if your players have IPv6 too. IPv6 and game servers explains how far that gets you, which for a public server is not far enough.

Why "host and invite" works when a server does not#

Here is the puzzle people run into: the same CGNAT connection that cannot run a dedicated server can host a co-op session that friends join through Steam invites. That is not a contradiction.

Player-hosted sessions in many games do not need an open port. Both sides start outbound connections to a rendezvous service, which tells each the other's public address and port. Each then sends packets to the other at the same moment, creating a mapping on its own NAT that lets the other's packets in. This is UDP hole punching, and with cone-type NATs on both ends it usually works, even through CGNAT.

When it fails - one side symmetric, or both behind restrictive carriers - the platform falls back to a relay. Steam's networking layer can route session traffic through Valve's relay network, and Valheim's crossplay sessions go through PlayFab's relay; other platforms have their own. Relayed traffic takes a detour and adds latency, but it connects.

A dedicated server reached by address cannot use any of this. The player knows an address and a port, sends a packet to it, and expects an answer. There is no rendezvous and no relay, so the packet meets a NAT with no mapping and disappears.

Timeouts and full tables: NAT problems after connecting#

Not every NAT problem stops a connection. Two show up after players are already in.

Mappings that expire mid-session. Every NAT between the player and the server keeps a UDP mapping alive only while packets flow. Games send state many times a second, so in play this never matters. It matters in quiet moments: a player sitting in a menu, a loading screen that stalls, a game that only sends updates when something changes. If the gap outlasts the shortest timeout on the path - a cheap home router or a carrier NAT tuned aggressively - the mapping is gone, and the server's next packet is dropped. The player sees a timeout disconnect "for no reason", usually at the same kind of moment each time. Games handle this with keep-alive packets, and most do it well; where a particular game does not, the fix is on the player's side (a router with longer UDP timeouts) rather than on the server.

A full connection-tracking table on your own box. If you run the server on your own Linux machine or a VDS with a stateful firewall, the kernel tracks every flow, and the table has a size limit. A flood of spoofed packets, or a very busy server plus a scanner, can fill it. When it does, the kernel log says so plainly:

nf_conntrack: nf_conntrack: table full, dropping packet

New players then fail to connect while existing ones carry on. Check the current count against the limit with cat /proc/sys/net/netfilter/nf_conntrack_count and nf_conntrack_max. Raising the limit helps against a busy server; against a flood, the answer is filtering upstream rather than a bigger table. Firewall rules that matter covers the ruleset side.

The ways out, compared#

Ask the ISP first. Many providers will move a customer off CGNAT on request, sometimes for free, sometimes as a paid "public IP" option, sometimes only on business tariffs. Ask specifically for a public IPv4 address, not just a "static IP", and confirm that the router's WAN address changes to a non-100.64 address afterwards.

IPv6 is free and clean if both ends have it, and useless for players who do not. Fine for four friends who checked; not a plan for a public server.

An overlay network puts everyone on a private network with each other. No ports, no NAT, no public exposure. Every player has to install and join, which limits it to groups that know each other.

A tunnel or relay gives your home server a public address on someone else's network and forwards traffic down an outbound connection from your house. It is the only way to run a public server behind CGNAT without changing ISP, and it has costs in latency and in losing the players' real addresses. Tunnels and proxies for game servers covers playit.gg, frp, WireGuard on a VPS and the trade-offs.

Moving the server out of the house removes the problem rather than working around it. A hosted server sits on a public address with no NAT that you have to think about. Hosting a game server at home vs renting one weighs the rest of that decision.

NAT you do not see on a hosted server#

Hosted servers are usually behind a small amount of NAT too, but of a kind that is configured for you. On a Pterodactyl-based panel, which RE:NODE runs, each server lives in its own container, and the node publishes the allocated ports from its public address into that container. Players connect to the node's address and the allocated port; the translation into the container is a fixed mapping, exactly like a port forward that someone else wrote and maintains.

Two side effects occasionally surface:

• The game sees a private address for itself. A few games print or advertise the address they think they are on. Inside a container that is a private address, which is harmless for connections but confusing in logs. The address to give players is the one on the server's page in the panel.
• The game sees players' real addresses. Unlike a tunnel, a port mapping keeps the source address of incoming packets, so bans, logs and per-IP limits work as normal.

On RE:NODE each plan lists how many ports it includes and extra ones - query, RCON - are added on the Network tab. There is nothing to forward and no CGNAT in the path, because the server is not behind anybody's home router.

FAQ#

Can I port forward behind CGNAT?

No. The port you would need to open is on the ISP's NAT, which you cannot configure. Your router's forward is correct but never receives the traffic. The fixes are a public IPv4 address from the ISP, IPv6, a tunnel or relay, or hosting the server elsewhere.

Is CGNAT the same as double NAT?

They look similar but differ in who owns the second NAT. Double NAT usually means two routers in your own home, such as the ISP's modem and your own router, and you can fix it with bridge mode. CGNAT is in the ISP's network, and only the ISP can change it.

Why does my NAT type say Strict?

Your connection does not allow unsolicited inbound traffic and maps ports in a way that defeats hole punching, often because of CGNAT or a restrictive router. You can still join dedicated servers normally; you will struggle to host player sessions or join some peer-to-peer lobbies.

Does a VPN fix CGNAT for hosting?

An ordinary consumer VPN does not, because it is also a shared NAT that does not forward ports to you. A VPN or tunnel service that explicitly offers port forwarding does, at the cost of extra latency and of your players' traffic passing through that provider.

Will my players' NAT type stop them joining my server?

Not if your server is on a public address. Players connect outward to the server, which every NAT type allows. NAT types only matter when one player's machine is acting as the host.