Full Cone NAT, Restricted Cone NAT and Symmetric RFC NAT Terminologies versus Vendor NAT Terminologies.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Full Cone NAT, Restricted Cone NAT and Symmetric RFC NAT Terminologies versus Vendor NAT Terminologies.

L2 Linker

When we talk about Stun Protocol used for NAT traversal in voip environment or SDWAN, 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 Palo Alto or Cisco, 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 Palo Alto or 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.

To conclude Symmetric NAT is another term of PAT from Cisco's perspective and Full Cone NAT is equal to Static NAT from Cisco's perspective.

 

Now what about Address Restricted Cone and Port Restricted Cone ?

 

Based on the logic of Address Restricted Cone, it behaves like Dynamic NAT. In Dynamic NAT there is no port translation, only the source IP is translated, in other words no port restriction. The returning packet from the external destination device is allowed on any port.

 

For the Port Restricted Cone and based on its behavior, it behaves like PAT because there is port restriction to allow the returning traffic.

 

If we look at the definition of Address Restricted NAT on RFC 3489, it says :

 

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

 

RFC 3489 has been obsoleted by RFC 5389 where it is stated in Section 2 :

 

"Furthermore, classic STUN's algorithm for classification of NAT types was found to be faulty, as many NATs did not fit cleanly into the types defined there."

 

This is the reason why the Cisco NAT Terminologies do not match with the original STUN RFC NAT Terminologies.

 

There are two types of NAT terminologies.

 

1-Cone/Symmetric Terminologies

2-NAT Vendor Terminologies (or I prefer to say NAT Behavior terminologies).

 

I think it is better to refer to NAT Vendor/Behavior terminologies instead of Cone/Symmetric NAT.

0 REPLIES 0
  • 2093 Views
  • 0 replies
  • 1 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!