Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
    
Before I answer, are you simply wanting to know why UDP hole punching doesn't work with symmetric NAT or are you asking about your particular issue? Because your issue doesn't necessarily seem related to either, so I'm curious. –  TheCleaner Aug 9 '13 at 21:06
    
OK, maybe you could explain both? I mean, why it doesn't work and why my issue doesn't seem related. –  john Aug 9 '13 at 21:09
    
Let's start with a chat room if you want to create one...I have a little time and it might be easier. I'll cut/paste my explanation from there as an answer here later. –  TheCleaner Aug 9 '13 at 21:10

2 Answers 2

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.

share|improve this answer
    
The remote support tool is Log Me In and is used by a couple of our 3rd party suppliers for support. We allowed the traffic on our company firewall, and could see the traffic being passed by the firewall. Nothing came back though. It's almost like there was no way back through the firewall, or the remote server couldn't determine where to send the return communication. –  john Aug 10 '13 at 6:20
    
We also have a proxies, so it's possible those are interfering in some way. –  john Aug 10 '13 at 8:23
    
If you have an outbound "allow policy" then it should work if your side initiates the traffic and that traffic is reaching the remote party with the right NAT info. See here too: help.logmein.com/… but you might need consulting or more onsite expertise to knock this out... –  TheCleaner Aug 13 '13 at 13:06

enter image description here

enter image description here

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.