Network address translation
Network Address Translation (English Network Address Translation , shortly NAT ) is in computer networks is the collective term for changes of addresses in the IP header of IP packets (Layer 3 of the ISO-OSI model).
NAT (more precisely SNAT) enables, among other things, the simultaneous use of a public address (see private IP addresses ) by several hosts. Usually, the router in the network takes over the SNAT that establishes the connection to the Internet (therefore this router is usually the default gateway of a host).
NAT is divided into Source-NAT (SNAT; German: " Quellen-NAT ") and Destination-NAT (DNAT; German: " Target NAT "). With source NAT, the address of the computer establishing the connection (source) is rewritten. With destination NAT, it is the address of the addressed computer (destination) that is rewritten.
Use of NAT
Use of source NAT
Source NAT is mostly used due to the scarcity of public IPv4 addresses and the tendency to connect more and more households (in which private subnets are used) to the Internet . The special form of SNAT is also called masquerading or masquerade , which is mainly used for dial-up connections. When masking, the sender address of the packet is automatically changed by an algorithm to the IP address of the interface on which the packet leaves the router, while with SNAT the (new) source address must be specified explicitly.
Source NAT is used as a kind of security feature and to separate internal and external networks, especially in private network installations or network installations that are as inexpensive as possible. By masking the source IP address, the internal computers can actually no longer be addressed directly from the outside, but this should rather be viewed as a side effect, since it neither replaces security infrastructure nor is it intended to separate networks.
Use of destination NAT
Destination NAT is used to change the destination of an IP packet. The most common use of DNAT is to change the public IP address of an Internet connection to the private IP address of a server in the private subnet. This method is known as "port forwarding" in connection with UDP / TCP connections. DNAT can therefore also be used to offer several different server services that are operated on different computers under a single (public) IP address . To differentiate DNAT, see also NAT-Traversal or NAT-T.
NAT router, NAT session and NAT table
A modern router with NAT function is stateful and is therefore also referred to as stateful. With stateful firewalling, the associated connection information (including IP addresses, protocol / ports and timeouts ) is stored in a session table (see netfilter - connection tracking ) for each connection requested by a client . The NAT router can then use the stored information to assign the respective response data packet to the correct client . After a session has expired, your entry is deleted from the session table. The number of sessions that a NAT router can keep open at the same time is limited by its main memory, 10,000 sessions only take up about 3 MB.
Each time a connection is established by an internal client, the internal source IP address is replaced by the router's public IP address. In addition, the source port of the internal client is replaced by a free port on the router if the source port is occupied. This assignment is saved in the session table (NAT table) of the router. The NAT router can then use the stored information to assign the respective response data packet to the correct client . The process is known as PAT (Port and Address Translation).
|local area network ( LAN )||public network ( WAN )|
===== = =====>
Source NAT and IP routing using the example
In this example, the private network uses the IP address 192.168.0.0/24. A source NAT router with the public address 126.96.36.199/32 is located between this network and the public Internet .
Routing is generally required whenever the sender and recipient are in different networks. If a station connected via a source NAT router wants to send a packet to a recipient outside of its (private) network, for example to a Telnet server somewhere remote on the Internet, the communication process works (in simplified form) as follows: First the station determines via DNS the destination IP of the Telnet server, and via the routing table the router closest to the desired destination (see routing table ), this is the source NAT router . The station then determines its MAC address via ARP and assembles a packet as follows: It receives the MAC address of the source NAT router as the destination MAC address , the destination IP address of the recipient (here 188.8.131.52 ), the destination port address 23 for the Telnet server as well as the MAC and IP address of the sender (here 192.168.0.4) and a sender port (any free high dynamic port ) for the Telnet session currently requesting as well as other data. The source NAT router receives and processes the packet because it is directed to its MAC address. When processing in the router, the packet is forwarded in a modified form: the router uses the recipient IP address to determine the next router , uses ARP to determine its MAC address and converts the packet as follows: It now receives the MAC address differently of the next router , the destination IP address of the recipient (184.108.40.206), destination port 23 and the public MAC and IP address of the source NAT router (220.127.116.11), a currently free sender port the reservoir of the router (here 49152) and the user data, which remain the same. This assignment of the original sender address and the port (192.168.0.4:49152) to the address tuple now contained (18.104.22.168:49152) is stored in the router until the Telnet session expires or is ended. NAT changes the packet on layer 3 ( IP ) significantly.
When processing in subsequent IP routers, the packet is only changed on layer 2: The router determines the next router , determines its MAC address via ARP and rebuilds the packet as follows: It now receives the different destination MAC address The MAC address of the next router and the sender MAC address are exchanged for your own. The IP address of the recipient (22.214.171.124), destination port 23 and the sender IP address of the source NAT router (126.96.36.199), its sender port 49152 and the user data are retained. This means: The packet is not changed here on layer 3 ( IP ). This process is repeated until a last router finds the target station in a directly connected network; The packet is then composed as follows: It receives the sender MAC address of the last router, the destination the MAC address of the destination station, the IP address of the recipient (= destination station, 188.8.131.52), destination port 23 as well as the IP address of the sender source NAT router (184.108.40.206), its sender port 49152 and of course user data.
After successful processing by the Telnet server, the response is then compiled as follows: MAC address of the router responsible for the return route (although the outward and return routes do not necessarily have to be identical), the IP address of the requesting source NAT router ( 220.127.116.11), the destination port address 49152 and the MAC and IP address of the Telnet server (18.104.22.168) and its sender port 23, as well as response data (payload). After all routers have been run through, the source NAT router (22.214.171.124) finally results in: MAC address and IP address of the requesting computer (here 192.168.0.4), and its port address 49152 and the MAC of the source NAT Router and IP address of the Telnet server (126.96.36.199) and its sender port 23, as well as response data. If this Telnet session is ended, port 49152 is also released again.
Each time a connection is established by the client, the destination IP address is replaced by that of the actual recipient in the LAN. In addition, the destination port is replaced by a free port on the router, which is then occupied. This assignment is saved in the router's NAT table.
|public network (WAN)||local area network (LAN)|
===== = =====>
RFC 3489 , which describes the STUN protocol for traversing NAT gateways, classified them in four different classes, which are also often used for classification outside of the STUN context:
|In the Full Cone NAT scenario, a gateway converts internal addresses and ports into an external address and its ports according to a static pattern. In particular, it also allows external hosts to establish connections to internal hosts via the external address of the NAT gateway. Full Cone NAT is also known as English port forwarding .|
|In the Restricted Cone NAT scenario, the gateway only allows an external host to contact an internal host if this connection attempt was preceded by contact between this internal host and the external host and the same destination port is used.|
|In the Restricted Cone NAT scenario, the gateway only allows an external host to contact an internal host if this connection attempt was preceded by contact between this internal host and the external host and the same destination port and the same source port are used.|
|In the Symmetric NAT scenario, each individual connection is made with a different source port; the restrictions are the same as in the Restricted Cone NAT scenario. Because each connection is assigned its own source port, initiation of connections by external hosts to internal is not or hardly possible.|
In modern NAT systems, however, these prototypical basic scenarios often only provide clues for the classification of specific behavior of the gateways. These sometimes use mixed forms of the classic approaches to address translation or dynamically switch between two or more behavioral patterns. RFC 3489 has been replaced by RFC 5389 , which no longer attempts this categorization.
- NAT helps to slow down the shortage of IPv4 addresses. It does this by replacing multiple addresses for multiple end systems with a single IP address.
- IP addresses of one network can be hidden from another network. Thus NAT can be used to improve privacy .
- The same IP address ranges can be used by several closed private networks without address collisions, since only the IP address of the NAT router is visible to the outside.
- One problem with NAT is that the proper assignment of "1 host with unique IP address" is not adhered to. By the definition of protocol headers that a man-in-the-middle attack is similar to those that especially older protocols and encryption at the network and transport level through this design breakdown problems ( eg. IPsec AH). Protocol complications from NAT are described in RFC 3027 .
- Likewise suffer particular network services that use out-of-band signaling and feedback channels, such as IP telephony protocols, including complications of NAT gateways.
- The end-to-end principle is violated when the NAT router changes the IP packet or TCP segment without it being the sending host.
Network Address Translation breaks the need for end-to-end connectivity. Applications that typically connect from host to host (for example, for peer-to-peer and IP telephony applications or VPN connections) therefore require NAT penetration techniques. Several techniques exist, none of which are universally applicable. Many techniques require the help of a server that is directly publicly accessible to both parties. Some methods use such a server only to establish the connection, others route all traffic on the connection through this auxiliary server.
Most of the methods often circumvent company security guidelines, which is why techniques are preferred in company networks that expressly cooperate with NAT and firewalls and allow administrative interventions at the NAT transfer point. The realm-specific IP and middlebox communication (MIDCOM) standards are rarely used.
SOCKS , the oldest protocol for NAT penetration, is widespread, but is being used less and less. With SOCKS, the client establishes a connection to the SOCKS gateway (this is usually directly connected to the Internet) so that the communication for the communication partner appears as if it came directly from the SOCKS gateway.
Home applications is Universal Plug and Play (UPnP) is used, resulting in a dynamic configuration port forwardings by the client itself allows one.
NAT-T is most frequently used with IPsec VPNs when encapsulating security payload packets are used on Internet connections with NAT routers. The ESP packets are packed in UDP / 4500 packets. Some routers also support ESP pass-through, so that the ESP packets can be passed directly to the VPN gateway and NAT-T is not required.
Another example of a NAT traversal protocol is STUN , which is very important in VoIP.
- Port forwarding
- Windows internet connection sharing
- NAT64 , translation between two protocol families
- Network Address Port Translation
- RFC 2663 . - IP Network Address Translator (NAT) Terminology and Considerations . [Errata: RFC 2663 ]. August 1999. (English).
- RFC 2766 . - Network Address Translation - Protocol Translation (NAT-PT) . February 2000. (Updated by RFC 3152 - Historic - English).
- RFC 3022 . - Traditional IP Network Address Translator (Traditional NAT) . [Errata: RFC 3022 ]. January 2001. (Replaces RFC 1631 - English).
- Tunnel through NAT gateways without the need to adapt the routers involved (English)
- Setting up NAT under Windows 2003 (English)
- NAT traversal test
- Peer-to-Peer Communication Across Network Address Translators (English)
- ↑ Understanding Network Address Translation. Microsoft , accessed December 9, 2015 .
- ↑ Olaf Kirch, Terry Dawson: Linux - Guide for Networkers . 2nd Edition. O'Reilly , 2001, ISBN 3-89721-135-1 , Chapter 11 - IP masquerade and the conversion of network addresses ( German and English online - original title: Linux Network Administrator's Guide . Translated by Peter Klicman and Ingo Marks).
- ↑ Network Address Translation (NAT) FAQ . Cisco Systems .
- ↑ a b c d RFC 1631 . - The IP Network Address Translator (NAT) . May 1994. ( Internet Engineering Task Force - English).
- ↑ M. Holdrege, P. Srisuresh: RFC 3027 . - Protocol Complications with the IP Network Address Translator . January 2001. (English).
- ^ Tony Hain: RFC 2993 . - Architectural Implications of NAT . (English).
- ↑ RFC 3102 , RFC 3103 , RFC 3104
- ↑ ietf.org ( Memento of the original from June 5, 2011 in the Internet Archive ) Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice.