I read this line from wikipedia.

"STUN does work with three types of NAT: full cone NAT, restricted cone NAT, and port restricted cone NAT. In the cases of restricted cone or port restricted cone NATs, the client must send out a packet to the endpoint before the NAT will allow packets from the endpoint through to the client. STUN does not work with symmetric NAT"

Can anyone explain why?

2 Answers 2


Because STUN(external server), cant know which port will be given to the client by NAT-device. In symmetric NAT, client gets unique port(ip:port in pool situation) on each connection


Let's say we have a STUN server at address stun_addr and a server at address srv_addr. Using STUN typically goes something like this:

  1. Client connects to the STUN server at stun_addr through NAT device. The NAT device translates the source address to natted_addr_1
  2. STUN server tells client the address from which it received the connection, which is natted_addr_1
  3. Client contacts the server at srv_addr through the NAT device, and tells the external system to use natted_addr_1 if it wants to reach the client
  4. External system sends something to the client using natted_addr_1

This will only work if the NAT device uses natted_addr_1 for both the communication to the STUN server and the other external system. More specifically, it only works if the NAT device will deliver the packets which arrive in step 4 to the client.

A symmetrical NAT device will use a different translation in steps 1 and 3 because the destination address of the traffic is different. In step 3, the source address in the packets to the server is translated to some other address natted_addr_2.

The NAT device only knows about these combinations of source and destination addresses and will only allow these back in:

  • From stun_addr to natted_addr_1
  • From srv_addr to natted_addr_2

Unfortunately, the server has been told to use natted_addr_1 but packets from srv_addr destined to natted_addr_1 will be rejected by the NAT device because of the NAT Address:Port restriction in-place.

To be more correct, 'address' should be replaced by 'address/port' in this answer, because NAT devices will work with the combination of IP address and port numbers.

  • Great explanation. This has helped me understand why STUN doesn't work for symmetric NATs. What I'm still struggling with is, in the world of WebRTC, will candidates generated via STUN on a address or port restrict cone NAT succeed? It seems to be in all of these cases, UDP hole punching is going to fail. Is my understanding correct?
    – Ternary
    Commented Oct 16, 2014 at 13:46
  • This sounds like a new question to me. Since terminology on different NAT-types can be confusing, ou could ask a new question on the site with some more context, if you like.
    – Gerben
    Commented Oct 16, 2014 at 18:16
  • Sure, here you go networkengineering.stackexchange.com/questions/12509/…
    – Ternary
    Commented Oct 16, 2014 at 18:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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