<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Full Cone NAT, Restricted Cone NAT and Symmetric RFC NAT Terminologies  versus Vendor NAT Terminologies. in Next-Generation Firewall Discussions</title>
    <link>https://live.paloaltonetworks.com/t5/next-generation-firewall/full-cone-nat-restricted-cone-nat-and-symmetric-rfc-nat/m-p/571309#M2331</link>
    <description>&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;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.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;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.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;The question is there a differences with Full Cone NAT and Symmetric NAT used as a references to explain Stun and Turn protocols?&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;The answer is in RFC 3489 for Stun Protocol.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;Section 5. NAT Variations&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;EM&gt;&lt;SPAN class="uiOutputText"&gt;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.&lt;/SPAN&gt;&lt;/EM&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;EM&gt;&lt;SPAN class="uiOutputText"&gt;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.&lt;/SPAN&gt;&lt;/EM&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;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.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;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.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;So we can conclude that the Full Cone NAT is defintely a Static NAT people traditionally used with many vendors.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;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.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;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.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;STRONG&gt;&lt;SPAN class="uiOutputText"&gt;Now what about Address Restricted Cone and Port Restricted Cone ?&lt;/SPAN&gt;&lt;/STRONG&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;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.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;For the Port Restricted Cone and based on its behavior, it behaves like PAT because there is port restriction to allow the returning traffic. &lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;If we look at the definition of Address Restricted NAT on RFC 3489, it says : &lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;EM&gt;&lt;SPAN class="uiOutputText"&gt;"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."&lt;/SPAN&gt;&lt;/EM&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;RFC 3489 has been obsoleted by RFC 5389 where it is stated in Section 2 :&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;EM&gt;&lt;SPAN class="uiOutputText"&gt;"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."&lt;/SPAN&gt;&lt;/EM&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;This is the reason why the Cisco NAT Terminologies do not match with the original STUN RFC NAT Terminologies. &lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;There are two types of NAT terminologies.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;1-Cone/Symmetric Terminologies&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;2-NAT Vendor Terminologies (or I prefer to say NAT Behavior terminologies).&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;I think it is better to refer to NAT Vendor/Behavior terminologies instead of Cone/Symmetric NAT.&lt;/SPAN&gt;&lt;/P&gt;</description>
    <pubDate>Sat, 30 Dec 2023 15:37:30 GMT</pubDate>
    <dc:creator>rmeddane</dc:creator>
    <dc:date>2023-12-30T15:37:30Z</dc:date>
    <item>
      <title>Full Cone NAT, Restricted Cone NAT and Symmetric RFC NAT Terminologies  versus Vendor NAT Terminologies.</title>
      <link>https://live.paloaltonetworks.com/t5/next-generation-firewall/full-cone-nat-restricted-cone-nat-and-symmetric-rfc-nat/m-p/571309#M2331</link>
      <description>&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;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.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;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.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;The question is there a differences with Full Cone NAT and Symmetric NAT used as a references to explain Stun and Turn protocols?&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;The answer is in RFC 3489 for Stun Protocol.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;Section 5. NAT Variations&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;EM&gt;&lt;SPAN class="uiOutputText"&gt;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.&lt;/SPAN&gt;&lt;/EM&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;EM&gt;&lt;SPAN class="uiOutputText"&gt;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.&lt;/SPAN&gt;&lt;/EM&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;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.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;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.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;So we can conclude that the Full Cone NAT is defintely a Static NAT people traditionally used with many vendors.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;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.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;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.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;STRONG&gt;&lt;SPAN class="uiOutputText"&gt;Now what about Address Restricted Cone and Port Restricted Cone ?&lt;/SPAN&gt;&lt;/STRONG&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;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.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;For the Port Restricted Cone and based on its behavior, it behaves like PAT because there is port restriction to allow the returning traffic. &lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;If we look at the definition of Address Restricted NAT on RFC 3489, it says : &lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;EM&gt;&lt;SPAN class="uiOutputText"&gt;"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."&lt;/SPAN&gt;&lt;/EM&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;RFC 3489 has been obsoleted by RFC 5389 where it is stated in Section 2 :&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;EM&gt;&lt;SPAN class="uiOutputText"&gt;"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."&lt;/SPAN&gt;&lt;/EM&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;This is the reason why the Cisco NAT Terminologies do not match with the original STUN RFC NAT Terminologies. &lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;There are two types of NAT terminologies.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;1-Cone/Symmetric Terminologies&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;2-NAT Vendor Terminologies (or I prefer to say NAT Behavior terminologies).&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN class="uiOutputText"&gt;I think it is better to refer to NAT Vendor/Behavior terminologies instead of Cone/Symmetric NAT.&lt;/SPAN&gt;&lt;/P&gt;</description>
      <pubDate>Sat, 30 Dec 2023 15:37:30 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/next-generation-firewall/full-cone-nat-restricted-cone-nat-and-symmetric-rfc-nat/m-p/571309#M2331</guid>
      <dc:creator>rmeddane</dc:creator>
      <dc:date>2023-12-30T15:37:30Z</dc:date>
    </item>
  </channel>
</rss>

