Re: [GD-General] NAT Negotiation

[Aaron D. <ri...@in...>]

This post seems like you are making the topic more complex than it really 
should be. 

NAT will typically take any _outgoing_ connection request, add it to a table 
on the NAT device, map the internal IP and port it to some external port 
(typically > 32000) on the NAT device, mangle the packet and sending. It  
performs the reverse translation for incoming data and most NAT devices 
support both TCP and UDP these days.

So, if you have a simple protocol in which all connections originate from 
_behind_ the NAT device, destined for the server, you won't have any issues. 
If you require connections that are initiated by the server or other clients 
however, you will run into trouble because (for fairly obvious reasons) 
sending packets to the NAT device for connections that are NOT in the NAT's 
table will not get them to the client machine.

On Mon, 12 Jan 2004 07:17 pm, Brett Bibby wrote:
> 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=3667950
>
> 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
> 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 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
> to be flippant or derogatory, but only to point out that A.) it's a
> 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
> in _theory_ (but rarely in practice, at least in the past 5 years or
> so), the reverse port mapping can change on a per packet basis.  This
> is described in a bit more detail in my article on multiplayer
> 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
> other _without opening up any ports_.  At least, that's my
> understanding.  This avoids the entire "explaining to users how NAT
> 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
> that you can tell users what ports to open/forward) but you should
> 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.
>
> No, you'll receive the other person's _public_ address and port
> mapping (ideally) that allows you to communicate with them directly.
> At least, that's what I'm assuming they're trying to do.  If you
> received 192.168.1.100, well, that's not too helpful since it'll just
> route to your own internal network (on a router that uses that
> mapping).
>
> Brian
>
> **End Brian Hook's Reply**
> **Begin Second Post**
>
> > This is precariously on the border of being OT and should probably be
> > 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
> > other _without opening up any ports_.  At least, that's my
> > understanding.  This avoids the entire "explaining to users how NAT
> > 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?
>
> > > 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.
>
> 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?
>
> > > 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.
> >
> > No, you'll receive the other person's _public_ address and port
> > mapping (ideally) that allows you to communicate with them directly.
> > At least, that's what I'm assuming they're trying to do.  If you
> > received 192.168.1.100, well, that's not too helpful since it'll just
> > route to your own internal network (on a router that uses that
> > mapping).
>
> 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**
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Perforce Software.
> Perforce is the Fast Software Configuration Management System offering
> advanced branching capabilities and atomic changes on 50+ platforms.
> Free Eval! http://www.perforce.com/perforce/loadprog.html
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_idU7

-- 
- Aaron

"Today's mighty oak is just yesterday's nut that held its ground."