Port forwarding vs hosted game servers

A port forward is a rule on your home router that says "unsolicited traffic arriving on this port belongs to that machine inside". You need one for every port a game server listens on, on the right protocol, pointing at an address that never changes - and it only works if your router actually holds a public IPv4 address, which is less common every year. A hosted server skips the whole layer: it already sits on a public address, so "forwarding" becomes "allocating a port", and the router, the ISP's NAT and your household's upload are no longer in the path. This post is about that network difference specifically - what the forward does, what breaks it, and what you trade when you move the server out of the house.

If you are still deciding whether to host at home at all, read hosting a game server at home vs renting one first; it covers electricity, uptime and cost. Here we stay on the wire.

What a port forward actually does#

Your router does network address translation. Every device in the house has a private address (192.168.1.x, 10.0.0.x), and the router rewrites outgoing packets so they appear to come from its single public address. It remembers each outgoing flow in a connection-tracking table, so when the reply comes back it knows which device to hand it to.

That table is the whole reason home networks are quietly safe by default, and the whole reason a game server at home does not work by default. A player connecting to your server sends the first packet. There is no entry in the table for it, because nothing inside started the conversation, so the router drops it.

A port forward is a static entry in that table, written by you:

Technically this is destination NAT: the router rewrites the destination of incoming packets from public-ip:2456 to 192.168.1.50:2456 and passes them on. The server answers, the router rewrites the source back, and the player sees a reply from the address they dialled. The server itself never knows a translation happened.

Three conditions have to hold for that to work, and each one fails in the wild:

1. The router's WAN side is a real public IPv4 address, not another private one.
2. The internal address in the rule is still the server's address.
3. Nothing else between the internet and the server - the ISP, a second router, the server's own firewall - drops the packet first.

The forwards common games need#

Most people forward one port and then wonder why the server is invisible. Games often need a second port for the server browser, and they care about protocol. These are the forwards for a home server at default settings; the full list with RCON and extras is in game server ports explained.

Two rules follow from that table. Forward exactly what the game uses, on exactly the protocol it uses - a TCP rule for a UDP game matches nothing and produces no error anywhere. And do not forward RCON or web-admin ports to the internet just because a guide listed them; administer from inside the house. RCON safely explains why that port is the one attackers look for.

Pin the internal address first

The forward points at an internal address. If the server machine gets its address from DHCP, it can receive a different one after a reboot or a long weekend switched off, and the forward then points at a printer. Make a DHCP reservation in the router, keyed to the server's MAC address, before you write any forward. Typing a static address on the machine itself also works, but only if you pick one outside the router's DHCP pool, which most people do not know the bounds of.

Open the machine's own firewall

The router passing the packet is half of it. Windows Defender Firewall blocks unsolicited inbound traffic too, and the "allow this app" prompt it shows on first launch is easy to dismiss or to answer for private networks only. An explicit rule is clearer:

New-NetFirewallRule -DisplayName "Valheim server" -Direction Inbound `  -Protocol UDP -LocalPort 2456-2457 -Action Allow

On Linux with ufw it is sudo ufw allow 2456:2457/udp. If the server is reachable from another PC in the house but not from outside, the machine's firewall is fine and the problem is upstream of it.

The router features that get in the way#

Consumer routers carry a handful of features that interact badly with game servers. None of them is exotic; most people meet at least one.

Double NAT

The most common hidden failure. Your ISP gave you a modem-router, and you plugged your own router into it. Now there are two NATs in a row: the ISP box has the public address, your router has a private address on the ISP box's network, and your server has a private address on yours. A forward on your router does nothing, because the packet never got past the first box.

You can spot it from the router's status page: if its WAN address is in 192.168.x.x, 10.x.x.x or 172.16-31.x.x, something in front of it is doing NAT. A traceroute from inside shows it too:

$ traceroute -n 1.1.1.1 1  192.168.1.1     0.6 ms 2  192.168.0.1     1.2 ms 3  100.72.14.1     8.9 ms ...

Two private hops in a row is double NAT in the house. A 100.64.0.0/10 address after them is the ISP's own carrier-grade NAT, which is a different and worse problem covered in NAT and CGNAT for game hosts. For in-house double NAT, the fixes in order of preference are: put the ISP box in bridge or modem-only mode so your router gets the public address; or set the ISP box to forward everything to your router (often called "exposed host" pointed at your router's address); or forward the ports on both boxes.

UPnP and NAT-PMP

UPnP lets software inside the house ask the router to open a port, without you. Some game servers and launchers use it to forward themselves automatically, and when it works, it is invisible. The problems are that it fails silently on many routers, that the lease can expire, and that any program on any device in the house can use it - including one you did not install on purpose. Most guides, including ours, recommend switching it off and writing the forwards by hand. If you leave it on, check the router's UPnP table occasionally to see what has opened itself.

Hairpin NAT, or why you cannot test from inside

Connecting to your own public address from inside your own network needs the router to turn the packet around and send it back in. That is called hairpin NAT or NAT loopback, and many consumer routers do not support it. The result is the most misleading test in home hosting: everything is correct, but you cannot join via your public address from your own PC, so you conclude the forward is broken.

Join with the LAN address from inside the house, and test the public address from outside - mobile data with wifi off, or a friend on another ISP.

Gaming features and ALGs

"Game mode", "gaming acceleration", SIP ALG and similar toggles rewrite or prioritise traffic in ways that occasionally break UDP flows. They rarely cause a forward to fail outright, but if a forward that should work does not, try with them off before you buy a new router.

Ports the ISP will not let in

Some residential ISPs block inbound traffic on a few ports on consumer lines - typically mail and web ports such as 25 and 80 - and say so in their terms. Game ports are rarely blocked, but a server you have moved to a well-known port to be clever may land on one. If a forward on a common web port fails while the same game on its default port works, that is the reason.

Addresses that move#

Two different addresses can change under a home server.

The internal one, solved above with a reservation. And the public one, which on most residential connections is dynamic: it changes when the router reconnects, when the ISP does maintenance, or on a fixed schedule. Every player who saved your server as an address now has a dead entry.

Dynamic DNS fixes the symptom. A small client - built into many routers, or a script on the server - updates an A record whenever the public address changes, and players use the name instead of the number. It works well with one caveat: the record has a TTL, and until it expires, resolvers keep handing out the old address. Keep the TTL short (60-300 seconds) on a dynamic record. Static IP addresses: when you need one goes through the options, and connecting a domain to a game server covers the record itself.

What a hosted server does differently#

On a hosted game server, the machine is in a datacentre on a public address. There is no NAT owned by you, no ISP box, no household sharing the upload. The equivalent of the port forward is the allocation: the host assigns your server an address and one or more ports, and the container is bound to exactly those.

On a Pterodactyl-based panel, which is what RE:NODE runs, that mapping is literal. Each server runs in its own container, and Wings, the daemon on the node, publishes the allocated ports from the node's public address into the container. The game inside binds to its port as usual. To players it looks exactly like a game server on a public address, because that is what it is.

What changes in practice:

• Nothing to forward. The allocation is the forward. On RE:NODE every plan states how many ports it includes, and extra ports - query, RCON - are added and removed on the Network tab. The game's own port setting lives on the Startup tab, so both halves of a port change are two tabs apart.
• No CGNAT, no double NAT. The address shown on the server page is the address players use.
• Your house is not the target. If someone floods the server, the flood lands on the datacentre's network, not on your living room's connection. On RE:NODE that means upstream filtering that drops obvious volumetric floods; attacks that look like real players are not filtered by anyone, and what we do about attacks is honest about the difference.
• The upload is not your household's. A busy server no longer competes with a video call upstairs, and the server's traffic is not billed per gigabyte - though unmetered is not a licence to saturate a shared uplink, as bandwidth and fair use explains.

What you give up is control of the edge. On a panel you do not write firewall rules for the node; the host decides what reaches the container, and the ports you have are the ports you were allocated. If you need to run a second service on an arbitrary port, it has to fit inside the allocation. On a VDS you get the full network stack back, with the full job of securing it.

Side by side#

The ping row deserves a sentence. When you host at home, you play at LAN latency and everyone else plays at internet latency to your house. In a fast shooter that is a real advantage, and in a co-op survival game nobody notices. A hosted server puts everyone, you included, on the same footing - and for a group spread across Europe, a server in Germany is often closer to the middle of the group than any one player's house. Where your game server should live has the numbers.

Testing a forward properly#

Whichever side of the line you are on, test in the same order, because each step isolates one layer.

1. Is the server listening, and on what? On Linux, ss -lnup for UDP and ss -lntp for TCP. On Windows, Get-NetUDPEndpoint -LocalPort 2456 or netstat -ano | findstr 2456. If the address is 127.0.0.1, the server is bound to loopback and nothing outside will ever reach it.
2. Can another machine on the LAN join with the LAN address? If not, the machine's firewall is blocking it.
3. Can an outside machine join with the public address and port? If the LAN works and outside does not, the problem is the router or the ISP: wrong protocol, wrong internal address, double NAT or CGNAT.
4. Does the server appear in the browser? If direct join works and the list does not, the query port is missing or the game needs a login token. Why a server does not show in the server list takes that case apart.

# From an outside machine: TCP games$ nc -vz 203.0.113.10 25565# UDP cannot be tested with nc honestly - an open and a filtered UDP# port look the same. Query the game instead (Steam games):$ python3 -c "import a2s; print(a2s.info(('203.0.113.10', 27015)))"

The second command needs pip install python-a2s and only works for games that answer Steam's A2S query; query ports and A2S explains the protocol and the tools. For a step-by-step version of this whole sequence with game error messages, see why players cannot connect to your server.

Choosing between them#

Port forwarding at home is the right answer when all of these are true: your router holds a real public IPv4 address, the group is small, the machine can stay on, and you accept that your home address is what players connect to. It costs nothing and teaches you a lot.

It stops being the right answer when any one of them breaks. CGNAT is the hard stop - no forward will ever work, and the workarounds are tunnels or relays covered in tunnels and proxies for game servers. An upload that cannot carry the player count, a public server that will attract attention, or a group that wants to play while you are away are the soft stops. At that point the forward is not the problem; the house is.

FAQ#

Do I need to port forward for a server I rent?

No. A rented server already has a public address, and the ports are allocated to it by the host. You only need to make sure the game is configured to use the ports you were given and that any second port, such as a query port, is allocated too.

Is UPnP safe to leave on for a game server?

It is convenient rather than dangerous in itself, but it lets any program on your network open inbound ports without asking, and it fails silently on many routers. Writing the forwards by hand and switching UPnP off is more predictable and leaves you knowing exactly what is open.

Why can I join my own server by LAN address but not by public address?

Usually because your router does not support hairpin NAT, so it cannot route a packet from inside back to its own public address. Test the public address from a different network, such as a phone on mobile data. If it works from there, nothing is wrong.

Can I forward the same port to two servers in the house?

No. One external port maps to one internal address. Run the second server on a different port and forward that one separately, and remember that games using the Steam query block around 27015 will clash unless you move their query ports too.

Does port forwarding slow the game down?

No. The translation is done in the router's hardware or kernel in microseconds. What slows a home server down is the household's upload queue filling up when someone else is using the connection, which shows up to players as latency spikes.