Of Games and NATs

This article, written in the mid-1990s, is well out of date. All games published since 2000 or 2001 have been "NAT-aware", due to the rise in popularity of cable modems and DSL. The only reason for explicitly opening ports these days is to run a server. The article is still here for historical interest.

Playing games through "home" routers

This page is about playing games on computers whose network connections run through a "home" router.  I classify a "home" router as a device that provides Network Address Translation (NAT) for a small number of hosts operated in an informal environment.  Generally, this means a couple of machines at home, connected to the Internet via a relatively slow network connection (56K dialup, consumer DSL, cable modem, ISDN), where you have control over the router's configuration.

Some examples of typical devices:

These devices can usually act as a DHCP server (so you don't have to manage IP addresses) and can be configured with a standard web browser.  They're perfect for a small business or a well-connected home.

Some of this discussion also applies to "IP masquerading", which is like NAT but it's done entirely in software.  If you don't want to buy a box and have a machine running Linux, you can configure it to do the work.  Many people find the configuration process difficult, so buying an easy-to-configure device may save you some trouble.

What is NAT?

Internet service providers hand out IP addresses when you connect (e.g. dialup PPP) or when you sign up (e.g. some cable modems).  In either case, the basic price gets you one address to use.  In situations where you can use more than one IP address, such as two machines sharing a DSL connection, you almost always have to pay extra.

With network address translation, you assign IP addresses to your hosts (generally in a "reserved" range, such as 10.* or 192.168.*) and use the NAT device (sometimes just called a "NAT") as a gateway.  All outbound traffic is rewritten so that it appears to be coming from the single public IP address, which is associated with the NAT.  Responses to your requests are rewritten and directed back to the appropriate machine.  This allows you to have many machines accessing the Internet, while only paying for a single IP address.

NATs also provide an improved level of security.  With most ISPs, when your machine is connected to the Internet, anybody can connect to your machine and (if it's configured poorly) access your files.  This is fine for experienced system administrators, but a little dangerous for the average user.  With a NAT between your computers and the outside world, nothing can connect directly to your machine unless you want allow it.  The only visible host is the NAT, and it will drop any packets that don't correspond to a connection you initiate.

It's possible, of course, that you might want users on the Internet to connect to one or more of your machines.  Access can be allowed by defining, by port and protocol, what inbound traffic is allowed and where it should go.  By default, anybody attempting to contact your machine will fail, becaue the NAT will simply ignore them.  If, however, you wanted to run a web server on one of your machines, you could tell the NAT to pass any traffic on TCP port 80 to your web host.

Why is this a problem for games?

Web surfing, FTP transfers, and telnet sessions use TCP to transfer data.  TCP is a connection-oriented, reliable protocol for moving data around.  It guarantees that packets will arrive, and that they will appear in the order that they were sent.

TCP is great for transferring data around, but lousy for action games.  If you're playing a first-person shooter, you need to see what's happening now, not what happened two seconds ago.  With TCP, if a packet gets dropped, no further packets will be accepted until the dropped packet arrives.  This results in "bursty" lag and a generally unpleasant gaming experience.

The UDP protocol does not guarantee that packets will show up in order or, for that matter, show up at all.  Most games are built on top of UDP because the protocol doesn't "get stuck" waiting for old packets.  The trouble with UDP is that UDP isn't connection-oriented, meaning that it isn't always possible to tell that a packet coming from a machine was in response to a packet sent to that machine.  This is where playing games on a NAT-connected machine becomes problematic.

NATs can deal with TCP automatically, because it establishes a connection between one of your machines and the remote host.  With UDP, it knows that a packet was sent to the remote host, and it can see a UDP packet coming back, but it can't necessarily know that one event is related to the other.  Some games automatically work with NATs, some don't. 

So, what do we do?

Most NAT devices can be configured to pass inbound UDP packets to a specific host, just like they can for inbound TCP connections.  If you can figure out what port the remote server is sending its packets to, you can configure your NAT to do what you want.  Some devices also have an all-or-nothing "DMZ" feature that allows you to specify a single machine as being wide open to all traffic.  When the feature is activated, the NAT passes all inbound TCP connections and all UDP packets to the DMZ host, just as if you had attached the machine directly to the Internet connection.

Playing games using a "DMZ" feature is simple; just open up the machine you're playing games on, hopefully after disabling any services that you don't want public, and start playing.  Opening ports for specific devices is more difficult, but doing so shouldn't expose the computer to security breaches.

For the devices mentioned earlier:

Bear in mind that these solutions require a single machine to be designated as the game host.  Because none of the local hosts have "real" IP addresses, all of the traffic for the game is sent to the one "public" address, and then redirected to the game machine.  There's no way for the NAT to route traffic for more than one machine, because the server can't address the machines directly.

Actually, I should say there's no general way to resolve the multiple-host problem.  Some games are "NAT aware" and can tell the device which packets to send where.

Examples for specific games follow.


Netrek is near and dear to my heart, because I wrote the UDP-based network protocols for it.  You can enable a verbose debugging mode to see exactly what it's doing, which comes in handy when you're trying to figure this silly NAT stuff out for the first time.  The game can be played over TCP, but UDP is greatly preferred.

The ".xtrekrc" configuration file allows you to specify the local UDP port, like this:

baseUdpLocalPort: 48020

This is the UDP port number that the Netrek client "binds" to.  The Netrek server will send its UDP packets there.  To make Netrek work, you just need to add a configuration item to the NAT that tells it to pass UDP port 48020 to the host on which you are going to play Netrek.

There are a couple of minor issues with this.  First off, you might want to play Netrek on more than one machine.  If you do, you need to specify a different baseUdpLocalPort for each machine, and add corresponding lines to the NAT config.  Second, the port number is the "base" port number, so if 48020 is already in use, the client will grab 48021.  In practice, unless you're sharing a single machine with multiple Netrek players, 48020 should always be available.

NOTE: if you get a "portswap" client, it will work unmodified through most NAT devices.

Half-Life (Team Fortress Classic)

It's a little harder to figure out what Half-Life is doing.  I cranked up TFC without modifying the NAT configuration and it worked, but judging by how choppy the play was, it appears that TFC will run over TCP if it can't get UDP packets through.  (Either that, or it's doing the automatic negotiation through the NAT, and I'm just imagining that opening a port makes a difference.)

When TFC is connecting to a multiplayer server, it spits out a bunch of console messages.  Near the top it tells you what port the server is on, and what port the client is on.  Generally, the server port is 27015, and the client port is 27005.  If you add UDP port 27005 to your NAT configuration, you should notice a dramatic improvement in game performance.  Port 27010 might be used as well.


According to the folks over at macsensetech.com, Diablo on battle.net servers doesn't require any special handling when used with the XRouter.  It uses port 6112, but does some sort of negotiation that allows the NAT to be configured automatically.  This feature may or may not apply to other NAT devices.

Other resources: