Saturday, 10 August 2013

Symmetric NAT and UDP Hole Punching

Symmetric NAT and UDP Hole Punching

I've read this question, but the explanation of Symmetric NAT wasn't
detailed enough.
Please could someone help me to understand the following paragraphs?
I read this about Symmetric NAT:
Each request from the same internal IP address and port to a specific
destination IP address and port is mapped to a unique external source IP
address and port, if the same internal host sends a packet even with the
same source address and port but to a different destination, a different
mapping is used. Only an external host that receives a packet from an
internal host can send a packet back.
http://en.wikipedia.org/wiki/Network_address_translation#Types_of_NAT
And this about UDP Hole-punching:
UDP hole punching will not work with symmetric NAT devices (also known as
bi-directional NAT) which tend to be found in large corporate networks. In
symmetric NAT, the NAT's mapping associated with the connection to the
well known STUN server is restricted to receiving data from the well-known
server, and therefore the NAT mapping the well-known server sees is not
useful information to the endpoint.
http://en.wikipedia.org/wiki/UDP_hole_punching
But I'm not really absorbing it. I get the feeling that it's telling me
that (in a client-server application where the client initiates the
communication) a server could not communicate back the other way unless it
were explicitly permitted by the NAT device. I don't understand why that
is what it's saying. If it's possible, could you simplify this description
slightly for me?
We have an issue in our environment where a well-known remote support tool
cannot be used by an equally well-known software vendor to provide support
to us. The client is proxy-aware, but for some reson it thinks it might be
a good idea not to use it and do something completely different via UDP on
port 1153.

No comments:

Post a Comment