[GD-General] NAT Negotiation

[Brett B. <res...@ga...>]

This thread is being transferred form the GD-Algorithms list as Brian =
pointed out it may be OT for the algorithms list. I apologize if this =
attempt to transfer doesn't go well :-)

**Original Post**

Yet another network post <sigh>...

I searched the archives for NAT and came up with 14 posts. Some say NAT =
is a problem, others say it's no problem especially when using a third =
server connected directly to the internet. Google results in a number of =
old pages, many with outdated links. My problem is that I need to come =
up with some sort of internal NAT solution (if it's really needed?) =
because we need to support multiple platforms, and I cannot find any =
third party solution (including Gamespy or open source) that covers all =
the platforms or compilable for them.

Let's say I have two machines, both behind NATs. They both think their =
address is 192.168.1.100, but to the outside world it's 123.123.123.123 =
and 124.124.124.124 (whatever). The only way for these two machines to =
ever find each other is through some third party, and they are at =
125.125.125.125.

They each get their address locally (192.168.1.100) and send that to the =
server in a packet it can understand. The server reads the packet and =
also notes the ip address of the received packet, so now the server has =
both the public and private address of a given client. It then sends =
each of the clients the other's address(es) and they try to contact each =
other.

Is this correct so far? Does it work because the NAT assigned different =
internal port numbers to the outgoing requests so it uses that to route =
the incoming packets back to the requestor? If so, this seems =
deceptively simple. Why does Gamespy mention they have to do other =
things too?

http://www.igda.org/oc/IGDAGamespyNAT.ppt

In a slide near the end they say they do some port guessing based upon =
common patterns. Why would they need this if a third party server is =
used?

Also, Brian Hook mentions in one of his posts in the archive about using =
the lower 16 bits of the ip address as a unique identifier. Why would I =
need to do this?

http://sourceforge.net/mailarchive/message.php?msg_id=3D3667950

There is also a mention that you shouldn't hard code port numbers. Is =
there a recommended way to generate one?

Finally, what if I am playing a game where two of us are behind a NAT on =
a LAN but connected to the same game on the internet. It's likely that I =
would recieve an address from the server of some other player's private =
address that would coincide with the address of my friend. When I =
contact them at that address they reply and I get the wrong connection. =
Is this what Brian was using the low 16 bits as an identifier for in =
order to distinguish between people using the same private address =
accidentally contacting another machine on their LAN?

Thanks
Brett

** End Original Post **
** Reply by Brian Hook**

This is precariously on the border of being OT and should probably be=20
handled on gd-general, but I don't think it's flagrant (but it's Tom's=20
list, so if he disagrees, we can take it to gd-general)

> I searched the archives for NAT and came up with 14 posts. Some say
> NAT is a problem, others say it's no problem especially when using

NAT is not a problem if you know what you're doing.  That's not meant=20
to be flippant or derogatory, but only to point out that A.) it's a=20
hairy problem to the uninitiated and B.) it's a solvable problem.

> They each get their address locally (192.168.1.100) and send that
> to the server in a packet it can understand. The server reads the
> packet and also notes the ip address of the received packet, so now
> the server has both the public and private address of a given
> client. It then sends each of the clients the other's address(es)
> and they try to contact each other.

Sounds about right.

> Is this correct so far? Does it work because the NAT assigned
> different internal port numbers to the outgoing requests so it uses
> that to route the incoming packets back to the requestor?

Yes, but you can't rely on this.  UDP is a connectionless protocol, so=20
in _theory_ (but rarely in practice, at least in the past 5 years or=20
so), the reverse port mapping can change on a per packet basis.  This=20
is described in a bit more detail in my article on multiplayer=20
programming you can find at bookofhook.com

> In a slide near the end they say they do some port guessing based
> upon common patterns. Why would they need this if a third party
> server is used?

What they're trying to do is allow two players to connect to each=20
other _without opening up any ports_.  At least, that's my=20
understanding.  This avoids the entire "explaining to users how NAT=20
works and why they can't host a server" problem.

> Also, Brian Hook mentions in one of his posts in the archive about
> using the lower 16 bits of the ip address as a unique identifier.
> Why would I need to do this?

To resolve clients behind a NAT.

> There is also a mention that you shouldn't hard code port numbers.
> Is there a recommended way to generate one?

Which port numbers?  For your server, you should hardcode them (so=20
that you can tell users what ports to open/forward) but you should=20
also allow them to be relocated in case there's a conflict.

> Finally, what if I am playing a game where two of us are behind a
> NAT on a LAN but connected to the same game on the internet. It's
> likely that I would recieve an address from the server of some
> other player's private address that would coincide with the address
> of my friend.=20

No, you'll receive the other person's _public_ address and port=20
mapping (ideally) that allows you to communicate with them directly. =20
At least, that's what I'm assuming they're trying to do.  If you=20
received 192.168.1.100, well, that's not too helpful since it'll just=20
route to your own internal network (on a router that uses that=20
mapping).

Brian

**End Brian Hook's Reply**
**Begin Second Post**

> This is precariously on the border of being OT and should probably be=20
> handled on gd-general, but I don't think it's flagrant (but it's Tom's =

> list, so if he disagrees, we can take it to gd-general)

I posted it here since there was discussion before on this list with no =
mention of OT at that time. Let me know if you want it moved to =
GD-General and I will do so immediately.

> What they're trying to do is allow two players to connect to each=20
> other _without opening up any ports_.  At least, that's my=20
> understanding.  This avoids the entire "explaining to users how NAT=20
> works and why they can't host a server" problem.

Couldn't they host a server as long as the third party matchmaking =
server game out thier public ip? Or is the rarely changing port number =
the problem here too? There isn't much difference between a client and a =
server once the third party matchmaking knows the correct ip and port =
number is there?

>=20
> > Also, Brian Hook mentions in one of his posts in the archive about
> > using the lower 16 bits of the ip address as a unique identifier.
> > Why would I need to do this?
>=20
> To resolve clients behind a NAT.
>=20

So this number would be used to identify players internally rather than =
ip/port, and when I want to send the packet I lookup the ip/port based =
upon this?
=20
> > Finally, what if I am playing a game where two of us are behind a
> > NAT on a LAN but connected to the same game on the internet. It's
> > likely that I would recieve an address from the server of some
> > other player's private address that would coincide with the address
> > of my friend.=20
>=20
> No, you'll receive the other person's _public_ address and port=20
> mapping (ideally) that allows you to communicate with them directly. =20
> At least, that's what I'm assuming they're trying to do.  If you=20
> received 192.168.1.100, well, that's not too helpful since it'll just=20
> route to your own internal network (on a router that uses that=20
> mapping).
>=20

Is this correct? So if I'm behind the same NAT as my friend, will the =
router detect the outgoing public ip address and port and reroute it =
back inside directly to them?

Brett

** End Second Post**