Project Zomboid Server CGNAT: Diagnose Your ISP's NAT

Carrier-grade NAT (CGNAT) can put another address-translation layer between your Project Zomboid server and the internet, outside your router’s control. A private or mismatched router WAN address is a clue, not proof that your ISP is the one doing it: a second home router or managed network can look similar. Compare the addresses privately, identify who owns the upstream layer, and ask your provider what options your account supports. This diagnoses a likely network boundary; it does not establish that any particular Project Zomboid connection route works.

What CGNAT means for a Project Zomboid server#

CGNAT is address sharing performed by an internet provider upstream of a customer’s own router. Several subscribers may share provider-side IPv4 addresses, while each home router still gives local devices private addresses. Your router can apply a forwarding rule to traffic it controls, but it cannot create a rule on equipment operated by the ISP.

That distinction matters when you host a server at home. An outside player’s connection may have to cross your router and another network layer before reaching the server. If the second layer is controlled by the provider, changing a setting on your own router does not change that upstream path. The address clues below can help identify where to ask questions, but they are not an end-to-end Project Zomboid connection test.

Keep three questions separate: does another NAT layer exist, who operates it, and can a compatible outside client actually join? An address comparison can suggest the first. Your network layout and ISP can help answer the second. Only a real test of the intended server and client path answers the third. Do not treat a CGNAT diagnosis as a workaround or a successful join.

Find the router’s WAN IPv4 without publishing it#

Open your router’s status or internet-connection page and look for the IPv4 address assigned to its WAN, internet, or uplink interface. Router interfaces vary by maker and firmware, so use the device’s own help if you cannot identify the field. Do not substitute a laptop’s Wi-Fi or Ethernet address: that is usually a local address assigned behind the router, not the router’s WAN address.

Write the WAN value down somewhere private. If your ISP supplied a gateway and you added a second router or mesh system, the address shown by the second device describes only its link to the gateway. You may need to inspect the gateway’s own internet status too, if you have legitimate access. Do not bypass a managed gateway or change its settings just to perform this check.

If your provider’s device hides the WAN address, note that limitation rather than guessing. You can still ask support whether the service uses a shared or upstream translated address. Never post a screenshot with a full public or private address in a forum, chat, or support ticket that does not need it. For most diagnosis, the address class and whether two values match are enough; the complete address is sensitive network information.

Compare it with an externally observed IPv4#

From a device on the same internet connection, use a reputable external IPv4 lookup page and privately compare its result with the router WAN value. Avoid pasting either full value into a public checker or article. The comparison points to a possible extra translation layer; it does not identify who operates that layer or prove that inbound traffic can reach your server.

What you see	What it suggests	What it cannot prove
WAN begins within 100.64.0.0/10	The address is in the shared range reserved for provider use by RFC 6598. Ask whether your ISP assigns it on a shared network.	It does not confirm your account’s routing policy or a working server path.
WAN is in 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16	It is within a private range defined by RFC 1918; another router or managed network may be upstream.	It does not distinguish an ISP gateway from a router in your home.
WAN differs from the external IPv4 result	Translation or another network boundary may sit upstream of the router you checked.	It does not establish that the ISP, rather than another local or managed device, owns that boundary.
WAN matches the external IPv4	No address difference appeared in this comparison.	It does not prove unsolicited inbound traffic is allowed or that a Project Zomboid client can join.

The 100.64.0.0/10 shared block is different from the RFC 1918 private blocks. A private or mismatched WAN value says an upstream translation is plausible; it does not by itself say “ISP CGNAT.” A globally formatted address, or a matching result, is not a reachability guarantee either. Keep the values private and use this as a clue for the next conversation, not a verdict about the game server.

Rule out a second router before calling it CGNAT#

Trace the equipment between the internet service and the computer running the server. A common layout is an ISP gateway followed by a personal router, Wi-Fi mesh, or another routing device. If the personal router receives an RFC 1918 address from the ISP gateway, the home may have two local routing layers. A campus, apartment, workplace, or other managed network can also place equipment outside your control between your router and the wider internet.

If you can see both devices’ status pages without changing settings, compare the personal router’s WAN address with the gateway’s internet address. If the gateway itself has a private or shared-range WAN, that is a reason to ask the ISP about another upstream layer. If you cannot access the upstream device, stop at “unresolved upstream boundary.” Do not assume its address or disable its security features.

This check prevents a common false conclusion: a private address on the router closest to your server proves only that this router has an upstream neighbor. The neighbor may be another device in your home, a building network, or provider equipment. Record which boxes you checked and which value was unavailable. Then ask the ISP or network administrator to identify the boundary rather than repeatedly adjusting the downstream router.

Ask your ISP who owns the upstream NAT#

Give provider support the service address or account details through its normal private support channel, but do not publish them. Explain that the router WAN value is in a private or shared range, or differs from the externally observed IPv4. Ask the representative to identify whether the service uses CGNAT, shared IPv4, or another ISP-controlled upstream NAT. Ask whether your account can receive an inbound-reachable public IPv4 and what current plan, price, address type, and terms apply.

You can also ask whether the address is dynamic or static, whether unsolicited inbound connections are filtered, and what supported option the provider recommends for a customer who operates a game server. The exact options and charges vary by provider and location, so do not rely on a generic guide to promise availability or quote a fee. Ask for the answer in writing and note the date, account plan, and any conditions the representative gives you.

If the provider confirms that your route accepts inbound traffic and your public address changes over time, see this guide to keeping a Project Zomboid server hostname current after a home IP change. DNS maintenance is a separate issue from identifying an upstream NAT.

If support says there is no provider NAT, ask them to identify what the WAN address belongs to and whether another service layer or managed gateway is involved. If they cannot confirm it, preserve the result as unknown. A confident answer from the ISP is more useful than inferring ownership from one address comparison, but it still does not substitute for testing the game connection after any network change.

Choose a next step only after the provider confirms the path#

Once you know which organization controls the upstream layer, choose an option that party actually supports. Your ISP might offer a different addressing option, explain a gateway you control, or say that the current connection cannot accept inbound traffic. Ask about the current terms before changing a plan or equipment. This article does not verify any particular ISP product, tunnel, VPN, relay, IPv6 route, or overlay as compatible with Project Zomboid.

If you would rather not maintain a home server and its network path, a managed server is another operating model to compare. Project Zomboid hosting provides a managed server environment with an integrated panel for server settings and restarts. That changes where the server is administered; it does not prove your friends’ client route, account, build, or mod setup will work, and it is not a tested CGNAT bypass. Confirm the service and game setup that fit your group before choosing it.

Do not choose a route just because it is described as a workaround for NAT in general. The Project Zomboid FAQ and the 42.21 Stable release notes do not document a CGNAT-specific route. A general networking feature is not evidence that the current Project Zomboid server and client support it. If the provider confirms an option and you decide to try it, treat the next stage as a separate compatibility and connection test.

Keep the diagnosis separate from a join test#

Before inviting the group, write down the provider’s answer, the path you chose, the server and client build/branch, and the exact external network used for the attempt. Have a compatible PC client join from outside the server’s home or hosting network using the intended address and method. Record whether it reaches the world or the exact message where it stops. If you have not run that test, the path is unverified.

An address match, router rule, or third-party port result cannot show every step of the client-to-server session. Nor does one address clue tell you whether a later failure comes from the server process, game version, access settings, or another network layer. For broader game-side checks, follow this Project Zomboid connection diagnostic path, which separates server readiness and local symptoms from an external attempt.

Keep a private record of the result and redact addresses, account details, passwords, and tokens before asking for help. If the provider confirms CGNAT and no supported inbound option, record that as the diagnosed constraint rather than claiming a route works. Revisit the hosting or network choice based on that answer, then verify any new setup with an actual external client before telling players the server is ready.

Quick answers

Does port forwarding work behind CGNAT?

A forwarding rule on your home router cannot control an ISP-operated upstream NAT. Ask the provider whether it offers a supported inbound path for your account.

Does a 100.64.x.x WAN address mean CGNAT?

An address in 100.64.0.0/10 is a strong clue for shared provider addressing, but ask your ISP to confirm how your connection is assigned.

What if my router WAN address is private but outside that range?

Check whether an ISP gateway, second router, mesh system, or managed network sits upstream, then ask your provider to identify the layer.

Does a matching public IPv4 guarantee friends can join?

No. Address comparison is only a clue; only a compatible client joining from outside the server network tests the complete route.