If players can join over your LAN but an external connection fails, check who controls the upstream IPv4 address before adding more router rules. A port forward on your router cannot, by itself, create a matching mapping in the provider's NAT. Reinstalling the game will not change that boundary.
This guide covers a directly reachable dedicated server. Games with their own relay or matchmaking service may follow a different connection path. You need access to the router's status page, the actual game ports and a player testing from another internet connection. Linux commands below inspect the host; Windows administrators can follow the same address comparison in their network and router interfaces.
Establish a working local endpoint first#
Start the server and wait for the game to report readiness. Join its private LAN address from another device using a compatible client. Record the exact address, port and protocol. Treat game traffic, server-browser queries and administration as separate endpoints; a successful query is weaker evidence than entering the world.
On Linux, inspect the host's IPv4 addresses:
ip -4 address show
This finds the server's interface addresses, not the WAN address of a separate router. A machine with 192.168.1.50 can still be reachable through correctly configured forwarding. Keep that private address stable with a DHCP reservation so the router does not later send traffic to another device.
If LAN joining already fails, resolve readiness, bind address, host firewall or client compatibility first. CGNAT is an external-path question; it does not explain a failed connection between two devices on the same reachable LAN.
Compare router WAN IPv4 with the observed external IPv4#
Open the router's internet status and record its WAN IPv4. Separately check the outgoing public IPv4 from that same home connection using an address-check service you trust. Disable VPN and proxy routing for this comparison, select IPv4 explicitly, and take both readings at the same time.
Do not compare the server's LAN address with a website's public address. They normally differ. A historical HomeNetworking discussion even contains a correction after a commenter reverses the router WAN and external address. That is a useful reminder to label the observations before interpreting them.
RFC 6598 reserves 100.64.0.0/10, covering 100.64.0.0–100.127.255.255, for shared address space. RFC 1918 defines private ranges 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. Seeing one on the actual upstream WAN suggests another boundary; identifying its owner is the next step.
A different WAN and observed external IPv4 suggests upstream translation, but does not alone identify provider CGNAT. Your own modem-router may perform the first translation. Matching addresses also do not prove incoming packets are permitted: provider filtering and local firewalls remain separate checks.
Find the owner of the second NAT boundary#
Draw the actual chain: server, personal router, provider modem-router, provider network. Inspect the WAN page on the outermost device you control. If both home devices route, this may be ordinary double NAT. You can arrange forwarding through both, or use a supported bridge/access-point configuration to remove one routing layer. Check the equipment instructions first; changing modes can interrupt internet or provider services.
If the upstream boundary belongs to the provider, ask support whether your subscription has CGNAT and whether they can supply reachable public IPv4 or an explicit inbound mapping. Do not assume a router DMZ setting or UPnP request propagates through their network. Dynamic DNS updates a name; it does not create an incoming route through NAT.
Choose an access method that fits the game#
A reachable public IPv4 from the provider is often the simplest arrangement. It need not be static: a changing address can work if players receive the current address or a correctly updated DNS name. Confirm incoming traffic is allowed and preserve the game's required protocol in every rule.
IPv6 is an option only when the server, client, game connection mechanism and both networks support it. A global IPv6 address still needs appropriate firewall permissions. Link-local addresses are not internet destinations; IPv6 on the router does not automatically make an IPv4-only game reachable.
A private overlay network can suit a closed group if every player can install and use its client. Check console restrictions and game discovery behavior. This is private access, not automatically a public browser listing.
For a relay or remote server, verify inbound UDP support where the game requires it, all game/query ports, region, latency and player compatibility. A TCP-only web tunnel cannot transparently replace a UDP game endpoint. Moving the server to your own reachable Linux host is another option; Nexardo can help manage your own infrastructure, while its actual network accessibility still depends on the host and provider.
Retest from another connection and keep the evidence#
After the chosen change, ask a player outside the home LAN to join the real advertised endpoint. Testing your public address from inside the same LAN depends on router loopback behavior and cannot substitute for this external check.
Record the server-ready time, WAN comparison, provider confirmation, intended UDP/TCP mappings and external join result. If packets still fail, continue with UDP diagnostics rather than reopening unrelated ports. The useful completion point is a player reaching the intended server over the intended route; obtaining a public address is only one step toward that result.
