Symmetric NAT and UDP Hole Punching

Question

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.

Answer 1

From our chat...so others may not get the full conversation, but the basics are here.

So basic NAT = source address:port >> external address:port >> NAT>> new source address:port >> external address port

with symmetric NAT it is a static mapping and the same every time and for both source AND destination.

Example: 192.168.100.5:34983 going to 4.2.2.2:53 then REQUIRE it to be 216.222.222.222:44444 with destination 8.8.8.8:333333

"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."

that part you say is incorrect it should read:

in a client-server application where the client initiates the communication) a server CAN communicate back the other way AFTER the source establishes the session OVER the ports used in the session.

Meaning if 2.2.2.2:43424 goes to 5.5.5.5:80 then 5.5.5.5:80 sends information back to 2.2.2.2:43424 once the session is established. In your sentence...the session would only ever be source communicating to destination with destination never replying with packets/info/graphics/whatever.

"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."

That could be because they simply block Logmein/Teamviewer/whatever at a port level since they ask to use a different port...so they think if you'll allow or communicate on 1153 it will circumvent their own IT restrictions...best I can think of without knowing in detail what app or full details. Nothing to do with symmetric NAT or UDP hole punching really...at least as far as the issue they are bringing up itself is concerned.

I would recommend talking to their support team on what remote support tool they do work with OR working with them to determine a way to use the tool you like. If it means certain port NATing/rules then you'll need to work with them and your Networking team to figure that part out.

Hope that all helps.

Answer 2

Look at these pictures taken from Wikipedia "Network address translation" page.

In "Full Cone NAT"

1. Once an internal address (iAddr:iPort) is mapped to an external address (eAddr:ePort), any packets from iAddr:iPort are sent through eAddr:ePort.
2. Any external host can send packets to iAddr:iPort by sending packets to eAddr:ePort.

In Symmetric NAT

1. 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.
2. Only an external host that receives a packet from an internal host can send a packet back.

Now lets discuss why UDP hole punching cannot work in Symmetric NAT. Lets say Server1 is STUN Server and Server 2 is NAT device of different Private Network. In UDP hole punching, Client connects with Server1 and port mapping is created on NAT device. But when this client connects to host behind Server2, NAT device creates another port mapping as shown in picture 2. Server1 shares the client port mapping with host behind Server2 and with this port mapping Server2 cannot make a connection and Server2 is not aware of the second port mapping created by NAT device.