Editing Network address translation (section)

==Applications affected by NAT==
Some [[application layer]] protocols, such as [[File Transfer Protocol]] (FTP) and [[Session Initiation Protocol]] (SIP), send explicit network addresses within their application data. File Transfer Protocol in active mode, for example, uses separate connections for control traffic (commands) and for data traffic (file contents). When requesting a file transfer, the host making the request identifies the corresponding data connection by its [[network layer]] and [[transport layer]] addresses. If the host making the request lies behind a simple NAT firewall, the translation of the IP address or TCP port number makes the information received by the server invalid. SIP commonly controls [[voice over IP]] calls, <!-- Calls also use H.323 in some systems -->and suffer the same problem. SIP and its accompanying [[Session Description Protocol]] may use multiple ports to set up a connection and transmit voice stream via [[Real-time Transport Protocol]]. IP addresses and port numbers are encoded in the payload data and must be known before the traversal of NATs. Without special techniques, such as [[STUN]], NAT behavior is unpredictable and communications may fail. [[Application Layer Gateway]] (ALG) software or hardware may correct these problems. An ALG software module running on a NAT firewall device updates any payload data made invalid by address translation. ALGs need to understand the higher-layer protocol that they need to fix, and so each protocol with this problem requires a separate ALG. For example, on many Linux systems, there are kernel modules called ''connection trackers'' that serve to implement ALGs. However, ALG cannot work if the protocol data is encrypted.

Another possible solution to this problem is to use [[NAT traversal]] techniques using protocols such as [[STUN]] or [[Interactive Connectivity Establishment]] (ICE), or proprietary approaches in a [[session border controller]]. NAT traversal is possible in both TCP- and UDP-based applications, but [[UDP hole punching|the UDP-based technique]] is simpler, more widely understood, and more compatible with legacy NATs.{{Citation needed|date=February 2011}} In either case, the high-level protocol must be designed with NAT traversal in mind, and it does not work reliably across symmetric NATs or other poorly behaved legacy NATs.

Other possibilities are [[Port Control Protocol]] (PCP),<ref name="rfc6887">{{Cite IETF|last=D. Wing|first=Ed|last2=Cheshire|first2=S.|last3=Boucadair|first3=M.|last4=Penno|first4=R.|last5=Selkirk|first5=P.|date=2013|title=Port Control Protocol (PCP)|rfc=6887|publisher=[[IETF]]}}</ref> [[NAT Port Mapping Protocol]] (NAT-PMP), or [[Internet Gateway Device Protocol]] but these require the NAT device to implement that protocol.

Most client–server protocols (FTP being the main exception{{efn|This issue can be avoided by using [[SSH File Transfer Protocol|SFTP]] instead of FTP}}), however, do not send layer 3 contact information and do not require any special treatment by NATs. In fact, avoiding NAT complications is practically a requirement when designing new higher-layer protocols today.

NATs can also cause problems where [[IPsec]] encryption is applied and in cases where multiple devices such as [[SIP phone]]s are located behind a NAT. Phones that encrypt their signaling with IPsec encapsulate the port information within an encrypted packet, meaning that NAT devices cannot access and translate the port. In these cases, the NAT devices revert to simple NAT operations. This means that all traffic returning to the NAT is mapped onto one client, causing service to more than one client behind the NAT to fail. There are a couple of solutions to this problem: one is to use [[Transport Layer Security|TLS]], which operates at [[layer 4]] and does not mask the port number; another is to encapsulate the IPsec within [[User Datagram Protocol|UDP]] – the latter being the solution chosen by [[TISPAN]] to achieve secure NAT traversal, or a NAT with [[NAT traversal|"IPsec Passthru"]] support; another is to [[NAT traversal with session border controllers|use a session border controller to help traverse the NAT]].

[[Interactive Connectivity Establishment]] (ICE) is a NAT traversal technique that does not rely on ALG support.

The DNS protocol vulnerability announced by [[Dan Kaminsky]] on July 8, 2008,<ref name="networkworld-2008-07-08">{{cite web |last1=Messmer |first1=Ellen |title=Major DNS flaw could disrupt the Internet |url=https://www.networkworld.com/news/2008/070808-dns-flaw-disrupts-internet.html |website=[[Network World]] |access-date=14 June 2021 |archive-url=https://web.archive.org/web/20090213171427/https://www.networkworld.com/news/2008/070808-dns-flaw-disrupts-internet.html |archive-date=2009-02-13 |date=2008-07-08}}</ref> is indirectly affected by NAT port mapping. To avoid [[DNS cache poisoning]], it is highly desirable not to translate UDP source port numbers of outgoing DNS requests from a DNS server behind a firewall that implements NAT. The recommended workaround for the DNS vulnerability is to make all caching DNS servers use randomized UDP source ports. If the NAT function de-randomizes the UDP source ports, the DNS server becomes vulnerable.