NAT traversal

{{Unreferenced section|date=February 2024}}

Network address translation typically uses private IP addresses on private networks with a single public IP address for the router facing the Internet. The network address translator changes the source address in network protocols for outgoing requests from that of an internal device to its external address, so that internal devices can communicate with hosts on the external network, while relaying replies back to the originating device.

This leaves the internal network ill-suited for hosting services, as the NAT device has no automatic method for determining the internal host for which incoming packets from the external network are destined. This is not a problem for general web access and email. However, applications such as peer-to-peer file sharing, VoIP services, and video game consoles require clients to be servers as well. Incoming requests cannot be easily correlated to the proper internal host. Furthermore, many of these types of services carry IP address and port number information in the application data, potentially requiring substitution with deep packet inspection.

Network address translation technologies are not standardized. As a result, the methods used for NAT traversal are often proprietary and poorly documented. Many traversal techniques require assistance from servers outside of the masqueraded network. Some methods use the server only when establishing the connection, while others are based on relaying all data through it, which increases the bandwidth requirements and latency, detrimental to real-time voice and video communications.

NAT traversal techniques usually bypass enterprise security policies. Enterprise security experts prefer techniques that explicitly cooperate with NAT and firewalls, allowing NAT traversal while still enabling marshalling at the NAT to enforce enterprise security policies. IETF standards based on this security model are Realm-Specific IP (RSIP) and middlebox communications (MIDCOM).

Various NAT traversal techniques have been developed:

• NAT Port Mapping Protocol (NAT-PMP) is a protocol introduced by Apple as an alternative to IGDP.
• Port Control Protocol (PCP) is a successor of NAT-PMP.
• UPnP Internet Gateway Device Protocol (UPnP IGD) is supported by many small NAT gateways in home or small office settings. It allows a device on a network to ask the router to open a port.
• Interactive Connectivity Establishment (ICE) is a complete protocol for using STUN and/or TURN to do NAT traversal while picking the best network route available. It fills in some of the missing pieces and deficiencies that were not mentioned by STUN specification.
• Session Traversal Utilities for NAT (STUN) is a standardized set of methods and a network protocol for NAT hole punching. It was designed for UDP but was also extended to TCP.
• Traversal Using Relays around NAT (TURN) is a relay protocol designed specifically for NAT traversal.
• NAT hole punching is a general technique that exploits how NATs handle some protocols (for example, UDP, TCP, or ICMP) to allow previously blocked packets through the NAT.
• UDP hole punching
• TCP hole punching
• ICMP hole punching
• Socket Secure (SOCKS) is a technology created in the early 1990s that uses proxy servers to relay traffic between networks or systems.
• Application-level gateway (ALG) techniques are a component of a firewall or NAT that provides configureable NAT traversal filters.{{cite journal|title=NAT Traversal Techniques and Peer-to-Peer Applications|citeseerx = 10.1.1.103.1659 | publisher=Helsinki University of Technology}}

It is claimed that this technique creates more problems than it solves.{{cite web|title=Introduction to NAT|url=http://www.pjsip.org/pjnath/docs/html/group__nat__intro.htm|website=PJNATH Library|access-date=2016-05-30}}

The recent proliferation of symmetric NATs has reduced NAT traversal success rates in many practical situations, such as for mobile and public Wi-Fi connections. Hole punching techniques, such as STUN and ICE, fail in traversing symmetric NATs without the help of a relay server, as is practiced in TURN. Techniques that traverse symmetric NATs by attempting to predict the next port to be opened by each NAT device were discovered in 2003 by Yutaka Takeda at Panasonic Communications Research Laboratory{{cite web|title=Symmetric NAT Traversal using STUN|url=http://tools.ietf.org/id/draft-takeda-symmetric-nat-traversal-00.txt}} and in 2008 by researchers at Waseda University.{{cite web|title=A New Method for Symmetric NAT Traversial in UDP and TCP|url=https://www.goto.info.waseda.ac.jp/~wei/file/wei-apan-v10.pdf|access-date=2016-05-14|archive-url=https://web.archive.org/web/20170202021103/https://www.goto.info.waseda.ac.jp/~wei/file/wei-apan-v10.pdf|archive-date=2017-02-02|url-status=dead}} Port prediction techniques are only effective with NAT devices that use known deterministic algorithms for port selection. This predictable yet non-static port allocation scheme is uncommon in large scale NATs such as those used in 4G LTE networks and therefore port prediction is largely ineffective on those mobile broadband networks.

IPsec virtual private network clients use NAT traversal in order to have Encapsulating Security Payload packets traverse NAT. IPsec uses several protocols in its operation which must be enabled to traverse firewalls and network address translators:

• Internet Key Exchange (IKE){{snd}} User Datagram Protocol (UDP) port 500
• Encapsulating Security Payload (ESP){{snd}} IP protocol number 50
• Authentication Header (AH){{snd}} IP protocol number 51
• IPsec NAT traversal{{snd}} UDP port 4500, if and only if NAT traversal is in use

Many routers provide explicit features, often called IPsec Passthrough.{{cn|date=July 2022}}

In Windows XP, NAT traversal is enabled by default, but in Windows XP with Service Pack 2 it has been disabled by default for the case when the VPN server is also behind a NAT device, because of a rare and controversial security issue.{{cite web|url=http://support.microsoft.com/kb/885348/en-us|archive-url=https://web.archive.org/web/20070104075252/http://support.microsoft.com/kb/885348/en-us|url-status=dead|archive-date=January 4, 2007|title=IPSec NAT Traversal is not recommended for Windows Server 2003 computers that are behind network address translators|publisher=Microsoft knowledge base #885348}} IPsec NAT-T patches are also available for Windows 2000, Windows NT and Windows 98.{{cn|date=July 2022}}

NAT traversal and IPsec may be used to enable opportunistic encryption of traffic between systems. NAT traversal allows systems behind NATs to request and establish secure connections on demand.

Hosted NAT traversal (HNT) is a set of mechanisms, including media relaying and latching, that is widely used by communications providers for historical and practical reasons.[https://datatracker.ietf.org/doc/html/rfc7362 Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication, RFC 7362] 2014-09-01 The IETF advises against using latching over the Internet and recommends ICE for security reasons.[https://datatracker.ietf.org/doc/html/rfc8445 Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal, RFC 8445 ] 2018-07-01

• {{IETF RFC|1579|link=no}}{{snd}} Firewall Friendly FTP
• {{IETF RFC|2663|link=no}}{{snd}} IP Network Address Translator (NAT) Terminology and Considerations
• {{IETF RFC|2709|link=no}}{{snd}} Security Model with Tunnel-mode IPsec for NAT Domains
• {{IETF RFC|2993|link=no}}{{snd}} Architectural Implications of NAT
• {{IETF RFC|3022|link=no}}{{snd}} Traditional IP Network Address Translator (Traditional NAT)
• {{IETF RFC|3027|link=no}}{{snd}} Protocol Complications with the IP Network Address Translator (NAT)
• {{IETF RFC|3235|link=no}}{{snd}} Network Address Translator (NAT)-Friendly Application Design Guidelines
• {{IETF RFC|3715|link=no}}{{snd}} IPsec-Network Address Translation (NAT) Compatibility
• {{IETF RFC|3947|link=no}}{{snd}} Negotiation of NAT-Traversal in the IKE{{clarify|expand acronym|date=July 2022}}
• {{IETF RFC|5128|link=no}}{{snd}} State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs)
• {{IETF RFC|5245|link=no}}{{snd}} Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols

• Session border controller (SBC)
• Port forwarding

{{reflist}}

• [http://www.holest.com/index.php/qp2p-nat-traversal-and-peer-to-peer-system/80-peer-to-peer-systems/86-nat-traversal-fundamentals.html Problems and fact about modern day NAT traversal systems]
• [http://samy.pl/pwnat/pwnat.pdf Autonomous NAT traversal – NAT to NAT communication without a third party]
• [http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat/ Cornell University – Characterization and Measurement of TCP Traversal through NATs and Firewalls]
• [http://www1.cs.columbia.edu/~library/TR-repository/reports/reports-2004/cucs-039-04.pdf Columbia University – An Analysis of the Skype Peer-to-Peer Internet Telephony]
• [http://www.brynosaurus.com/pub/net/p2pnat/ Peer to peer communication across Network Address Translators (UDP Hole Punching)]

Category:Computer network security

Category:Network protocols

Category:Network address translation