Even games that are 100% client/server sometimes have issues when the client is behind NAT. Peee-peer games are even a bigger issues. Some games need to use multiple transports (such as UDP and TCP) or multiple connections (such as a different UDP port for voice).

What are some ways to make sure a game works reliably when running behind a NAT router?

  • Peer-Peer: No centralized server exists. Player A starts a game and Player B wants to join
  • Client-Server: A centralized server on a well known address (hostname) accepts all incoming connections. Each client only communicates with that server.
  • Combo: Where the server is just matchmaking, but game updates are peer-peer. Different peers may see each player with a different IP/port potentially (e.g. some clients are behind the same NAT and some are on a different router)

The technique most commonly used is referred to as NAT punch-through. Here's a decent intro: http://www.mindcontrol.org/~hplus/nat-punch.html

There's an OSS project at least for UDP: http://udt.sourceforge.net/index.html

RakNet supports punch-through, too, I believe. It's commercial, but has a free "Indie" license. See here: http://www.jenkinssoftware.com/

Googling for "NAT punch" will get you plenty more reading material

  • 1
    \$\begingroup\$ I know this is a really old question and answer but if anyone reads this, RakNet is acquired by OculusVR and now open-source with 2-clause BSD license. github.com/OculusVR/RakNet \$\endgroup\$
    – Quad
    Jul 30 '14 at 18:21
  • Don't have a client inform the server or peer of its own address. In other words, don't embed client A's IP in a game packet and have client B or the server reply to that address. Always reply to the address/port that the message originated from.

  • Minimize the different UDP or TCP ports used for the game. This makes setting up NAT rules easier.

  • Allow the user to override the default port used in the game. This way several servers can be hosted behind the same NAT.

  • Document the ports and any rules they follow in your game documentation (thanks for that one Zorba). In Descent 3 I went as far as creating a stand alone test application that would help you troubleshoot your router or NAT configuration by sending packets to a test server.
  • 7
    \$\begingroup\$ In addition to this otherwise-good reply, include a note of the game ports in the game documentation. It's amazing how many games don't do this - people root out the ports manually with "netstat" and get half of them wrong. \$\endgroup\$
    – ZorbaTHut
    Jul 17 '10 at 14:14
  • \$\begingroup\$ With UDP, you don't really know where the message originated from. Anything can be written in the return address. \$\endgroup\$
    – MickLH
    Jun 11 '16 at 23:22

Along with other answers, use an existing wheel : http://miniupnp.free.fr/ This library battles almost all of the annoyances in function form , giving you control over when and how to punch and pull :)


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.