[OT] Handling multiple UDP clients through NAT

Shane Hathaway shane at hathawaymix.org
Wed Feb 7 18:16:08 MST 2007

Steve wrote:
> While designing my new MUD server I ran into a design problem that I'm
> hoping someone here has had experience with.
> Specifically, I currently keep track of clients in a hashmap, with the
> hash being comprised of their IP address and port.
> This works very well until multiple clients who are NAT'd try to connect.
> Now my initial response to this was to have each client bind a
> listener to a random port, then send a discovery request to the server
> that contains the port that they bound their listener to.
> That kind of works, except that some NAT Gateways and routers
> (specifically my own ActionTec Gateway POS from Qwest), block
> unsolicited incoming UDP packets on all ports regardless of if the
> same IP address is responding, as was used in the initial request, if
> the response packet is coming in on a port different than the one the
> original discovery packet was sent from.

That's correct.  The router has to choose the port number, not your 
server.  Your server must reply to the address and port provided in the 
IP header of a packet from the client.  You mentioned your application 
uses some kind of discovery request.  That discovery request adds an 
entry to an internal table in the router.  The internal table maps 
packets sent from the server to the router on a specific port back to 
the host that sent the discovery request.  The discovery request creates 
a virtual connection and you must use that connection for the duration 
of the session.

Your application doesn't need to do anything special to work around NAT 
except recognize that the client does not know its own IP address or 
port.  The server must infer the address and port of the client from the 
IP header of the first packet.

> I've looked at protocols like STUN, but there is so much overhead in
> the final binary, that I'ld really rather not try and implement all of
> that.

The purpose of STUN is to make a peer-to-peer connection between two 
hosts that are both behind masquerading firewalls.  STUN is tricky, but 
depending on the firewalls, a connection can usually be made with the 
help of an intermediary.  If either of the peers has a public IP 
address, STUN is an unnecessary complication.


More information about the PLUG mailing list