When we talk about Stun Protocol used for NAT traversal in voip environment, the common term used when talking about the Type of NAT that is compatible with Stun is “Full Cone NAT”, then when we explain why Turn Protocol is developped to replace Stun Protocol, the most common reason is “Symmetric NAT is not compatible with Stun”. These terms of “Full Cone NAT” and “Symmetric” cause many confusions.
For some people who traditionally work with different vendors like Cisco, F5, Fortinet, different terms of NAT are used, the most common NAT Types used in many vendors are: PAT, Static NAT SNAT, Dynamic NAT.
The question is there a differences with Full Cone NAT and Symmetric NAT used as a references to explain Stun and Turn protocols?
The answer is in RFC 3489 for Stun Protocol.
Section 5. NAT Variations
Full Cone: A full cone NAT is one where all requests from the same internal IP address and port are mapped to the same external IP address and port. Furthermore, any external host can send a packet to the internal host, by sending a packet to the mapped external address.
Symmetric: A symmetric NAT is one where all requests from the same internal IP address and port, to a specific destination IP address and port, are mapped to the same external IP address and port. If the same host sends a packet with the same source address and port, but to a different destination, a different mapping is used. Furthermore, only the external host that receives a packet can send a UDP packet back to the internal host.
If we look at RFC 3489 in section: 5. Variations, the Full Cone NAT means that the private IP and port of an internal host are always mapped or translated to the same public IP and port when going to internet, this means that from this point of view, this internal host is reachable from internet using its own public IP and Port. In vendor’s language, this type of NAT behavior is called Static NAT.
From, let’s say Cisco vendor a Static NAT allows the mapping of public IP Addresses to hosts inside the internal network. In simple english, this means you can have a computer or a server on your private network that exists on the Internet with its own real IP. It is one-to-one mapping of a private IP address to a public IP address, or private IP/Port to a public IP/Port.
So we can conclude that the Full Cone NAT is defintely a Static NAT people traditionally used with many vendors.
For Symmetric NAT, RFC 3489 explains this kind of NAT as follow: internal host’s IP/Port are translated to different public/port when going to different destination on the internet. And it add an interesting sentence: only the external host that receives a packet can send packet back to the internal host, this means that this internal host is not reachable directly from internet like the Full Cone NAT but after initiating a traffic then the response is sent back to this host.
From the vendors’s perspective such as Cisco, the Dynamic NAT and PAT are similar to Symmetric as explained by RFC 3489. Dynamic NAT can be defined as a dynamic mapping of a private IP address to a public IP address from a group of public IP addresses called as NAT pool, so a private IP address can be translated to different public IP since this mapping is dynamic.
Port Address Translation (PAT) is another type of dynamic NAT which can map multiple private IP addresses to a single public IP address by using a technology known as Port Address Translation. Here when a client from inside network communicate to a host in the internet, the router changes the source port (TCP or UDP) number with another port number.
The issues of Dynamic NAT and PAT is the internal host cannot be reached directly by an external host.
So finally Full Cone NAT is our Static NAT we usually configure on our routers and firewalls while the Symmetric NAT is finally the Dynamic NAT or PAT we commonly use on our infrastructure.
Hello there, I was lurking the Webex API and noticed that Events (classic) has very poor functionalities via API... but now we have Events NEW! So my hope is that Events New will have more stuff available... has anyone any news on this? Is there a site in...
Hello, I am trying to register a new VG450 to CUCM as a SIP Gateway. This is working as expected, but I also need to be able to register the same VG450 as SCCP and MGCP. MGCP is fine, since it uses hostname.domain, SCCP is NOT working as it uses...
How to get Agent details who handled the call after "call Place step" from Script (callback script)? Im struggling to get agent details who handled the call after having a call place step in call back script. It shows NULL value.. &nb...
i've been testing UCCX 11.6 SSO with Azure as IDP, there is no real document available which gives the steps to perform on Azure side, i found a document for CuCM, which worked with CuCM at the first attempt, i thought to replicate it for UCCX , taking be...
We are deploying a UCCE 12.6 system Now the LiveData component is properly connected with the CUIC component. I see that the data source of LiveData is normal on the CUIC component. But when I imported the liveData report, I found no data displa...