NAT Traversal
NAT Traversal
As IPv4 addresses are exhausted, NAT is deployed more and more on home networks and carriers' networks. To prevent attacks from public networks and protect intranet hosts, NAT-enabled devices drop some packets sent from public networks to the intranet. Therefore, although NAT technology solves the problem of IPv4 address shortage and enhances network security, it interrupts communication on some point-to-point (P2P) networks. A P2P network requires that devices at both ends can initiate access to each other. Therefore, the larger deployment of NAT builds a barrier to the normal running of P2P applications.
ALG makes NAT work with protocols at the application layer, such as DNS and FTP. It is widely used by NAT device vendors and has become a mandatory function of NAT devices. For details, see NAT ALG.
Hole punching is more universally used for NAT traversal. Simple Traversal of UDP Through NAT (STUN) is widely used because it is a lightweight hole punching technique that enables NAT traversal for UDP connections, works with existing NAT devices, and does not require any additional operation. For details, see NAT STUN.
NAT Mapping and Filtering
NAT mapping and NAT filtering are used in the NAT traversal technology. For example, in NAT ALG for SIP, you need to configure address and port-dependent mapping (APDM) and address and port-dependent filtering (APDF) to enable SIP proxy to traverse NAT devices; in STUN, you can determine NAT behavior types based on the NAT mapping and filtering type, so as to determine whether STUN can work properly. Therefore, before learning the NAT traversal technology, you need to understand the basic concepts and types of NAT mapping and filtering.
Basic Concepts
Endpoint: a combination of IP address and port number. It is a basic concept in NAT.
NAT mapping: a process in which the NAT device maps the private IP address of a packet into a public IP address. When an intranet host initiates an access request to an extranet host, the NAT device establishes a mapping between the intranet endpoint and extranet endpoint, translates the intranet endpoint to the extranet endpoint, and forwards the packet to the extranet endpoint. The Router supports three types of NAT mapping, which will be further detailed later.
NAT filtering: a process in which the NAT device filters the traffic from public networks to private networks. To prevent intranet hosts from being attacked, the NAT device filters out invalid packets and forwards normal communication packets. The Router supports three types of NAT filtering, which will be further detailed later.
NAT Mapping
Endpoint-independent mapping (EIM): An intranet endpoint is mapped to a fixed extranet endpoint. For example, Endpoint (X,x) is mapped to Endpoint (M,m). That is, the NAT uses the same address and port mapping for subsequent packets that are sent from the same private IP address and port to any public IP address and port.
Address-dependent mapping (ADM): When a packet is sent from Endpoint (X, x) to Endpoint (D1, d1) and Endpoint (D2, d2), Endpoint (X, x) is mapped into Endpoint (M1, m1) and Endpoint (M2, m2), respectively. If D1 is equal to D2, Endpoint (M1, m1) is the same as Endpoint (M2, m2). That is, the NAT uses the same mapping for subsequent packets that are sent from the same private IP address and port to the same public IP address, regardless of the extranet port.
Address and port-dependent mapping (APDM): When a packet is sent from Endpoint (X, x) to Endpoint (D1, d1) and Endpoint (D2, d2), Endpoint (X, x) is mapped into Endpoint (M1, m1) and Endpoint (M2, m2), respectively. If D1 is equal to D2 and d1 is equal to d2, Endpoint (M1,m1) is the same as Endpoint (M2,m2). That is, the NAT uses the same mapping for subsequent packets sent from the same private IP address and port to the same public IP address and port.
NAT Filtering
Endpoint-independent filtering (EIF): If Endpoint (X,x) has sent packets to public networks, extranet hosts can obtain its NAT-mapped Endpoint (M,m). The NAT performs the mapping and forwards any packet destined to Endpoint (M,m), regardless of whether the source public address is D1 or D2, and drops all the other packets.
Address-dependent filtering (ADF): If Endpoint (X,x) has sent packets to an extranet host whose IP address is D1, the NAT performs the mapping and forwards any packet sourced from host D1 and carrying any port number to the private network, and drops all the other packets.
Address and port-dependent filtering (APDF): If Endpoint (X,x) has sent packets to Endpoint (D1,d1), the NAT performs the mapping and forwards any packet sourced from Endpoint (D1,d1), to the private network, and drops all the other packets.
NAT ALG
As a NAT traversal technique commonly used on P2P networks, ALG solves the problem that IP addresses or port numbers contained in the Data field of application-layer protocol packets cannot be translated using NAT. For some special protocols such as FTP, IP addresses or port numbers may be contained in the Data field of the protocol packets. Since NAT can translate only IP addresses in the IP header and port numbers in the TCP/UDP header, some protocol packets cannot be translated using NAT. For example, when an FTP server on the private network attempts to set up a session with a host on the public network, the FTP server may need to send its private IP address to the host. NAT cannot translate this IP address because the IP address is carried in the Data field. When the host attempts to use the received private IP address to access the FTP server, the FTP server is unreachable. NAT ALG addresses the problem of translating IP addresses or port numbers contained in the Data field of application protocol packets.
NAT ALG Implementation
NAT ALG uses the NAT device with the ALG function to make NAT work with specific application-layer protocols. When detecting a new connection request, the NAT device determines whether the application is known based on the port information at the transport layer. If the application is a known application, the ALG function of the application protocol is enabled to check the payload of the application packet. If any IP address and port information is found, NAT translates the information and creates an additional mapping entry for the new connection. When the package reaches the destination host on the public network, the information carried in the packet is the translated IP address and port number. In this way, packets of certain application protocols can traverse NAT.
Application Protocol |
Fields that NAT Can Process |
|---|---|
ICMP |
IP header (including the UDP/TCP port number) in the payload of an ICMP error packet NOTE:
By default, the NAT ALG function is enabled for ICMP, regardless of whether NAT ALG is enabled on the device. |
DNS |
IP and Port fields in a response packet |
FTP |
|
SIP |
|
PPTP |
There are two scenarios:
|
RTSP |
Port field in a setup/reply OK packet |
NAT ALG Support for ICMP
In Figure 5-14, a public network host attempts to access a private network FTP server with a public IP address of 1.1.1.1. If port 21 on the FTP server is disabled, the FTP server sends an ICMP error message to the public network host.
The data payload of the ICMP error message carries a private IP address. Without the NAT ALG function, the NAT device forwards the message to the public network host without processing the private IP address in the data payload. Upon receipt of the message, the public network cannot identify the application to which the message belongs. In addition, the private IP address of the private network FTP server is leaked to the public network.
With the NAT AGL function, the NAT device translates the private IP address of 192.168.0.10 of the FTP server to a public IP address of 1.1.1.1 and then forwards the ICMP message to the public network host. Upon receipt of the ICMP message, the host can properly identify the FTP application. In addition, the risk of leaking the private IP address of the FTP server to the public network is eliminated.
NAT STUN
Overview of STUN
Definition
Session Traversal Utilities for NAT (STUN) is an RFC-defined network protocol that serves as a tool for other protocols (such as SIP, FTP, and DNS) in dealing with NAT traversal. STUN can be used to check the existence of a NAT device on a network and determine the IP addresses and port numbers allocated by the NAT device to two communication endpoints. A data channel used for NAT traversal can be automatically established through Interactive Connectivity Establishment (ICE).
Purpose
On the Internet, most computer hosts are located behind NAT devices. Only a few hosts can access the Internet directly. In most cases, two hosts on the network want to communicate with each other directly without using other devices. Because hosts are located behind NAT devices, before communication, they need to check the existence of NAT devices to confirm that NAT traversal needs to be performed during communication.
Currently, although some protocols provide a method for detecting NAT devices and performing NAT traversal, this implementation method is closely related to the connection establishment protocol selected by network services. Therefore, a common solution is required to solve the NAT traversal problem. STUN technology is introduced to solve this problem. It allows the device behind a NAT device to find the IP address and port number allocated by the NAT device. The information is used to create UDP communication between two hosts behind the NAT device.
To save IP address resources in an SD-WAN solution, users at the branch sites often use post-NAT private IP addresses to access the headquarters. NAT traversal is often required for traffic between the headquarters and branches and between branches. To implement NAT traversal for server traffic between branches, NAT detection of STUN is added in the SD-WAN EVPN function.
Benefits
STUN technology has the following advantages:
- Automatically discovers whether a NAT device exists on the network.
- Automatically creates a data channel for NAT traversal through Interactive Connectivity Establishment (ICE).
Basic Concepts of STUN
Before learning STUN, it is important to understand typical STUN networking and NAT types.
Typical Networking
STUN uses the client/server model and consists of the STUN client and STUN server. Figure 5-15 shows the typical STUN networking.
STUN client: is an entity that sends STUN binding requests and receives STUN binding responses, for example, a router.
STUN server: is an entity that sends STUN binding responses and receives STUN binding requests, for example, a router. A STUN server is usually deployed on a public network.
Through packet exchange with a STUN server, a STUN client can detect the existence of a NAT device and determine the IP address and port number allocated by the NAT device. After a data channel is established between STUN clients, PCs can access each other. For details about packet exchange, seeSTUN Implementation.
Currently, STUN does not support the scenario where a STUN server is deployed behind a NAT device.
NAT Types
In the STUN standard, NAT is classified into four types based on the mapping between the private IP address+port and public IP address+port of an NAT egress, as shown in Figure 5-16.
Full cone NAT
This type of NAT maps all requests from the same private IP address and port (IP1:Port1) to the same public IP address and port (IP:Port). Any external host can send a packet to an internal host only if the internal host had previously sent a packet through NAT.
This NAT mode allows all hosts on the Internet to access the hosts behind NAT as long as the mapping between private IP address+port and public IP address+port is created.
Restricted cone NAT
This type of NAT maps all requests from the same private IP address and port (IP1:Port1) to the same public IP address and port (IP:Port). Unlike full cone NAT, restricted cone NAT allows an external host (with IP address X) to send a packet to an internal host only if the internal host had previously sent a packet to the IP address X.
Port Restricted Cone NAT
This type of NAT maps all requests from the same private IP address and port to the same public IP address and port. An external host (IP2:Port2) can send a packet to an internal host only if the internal host had previously sent a packet to IP2 and Port2.
Symmetric NAT
In symmetric NAT, all requests from the same private IP address and port to a specific destination IP address and port are mapped to the same public 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 packet back to the internal host.
Port restricted cone NAT maps all requests to the same public IP address and port, while symmetric NAT maps different requests to different public IP addresses and ports.
- One end uses port restricted cone NAT and the other uses symmetric NAT.
- Both ends use symmetric NAT.
NAT Type Identification
STUN is a protocol sensitive to NAT behaviors. It supports only full-cone NAT, restricted-cone NAT, and port-restricted cone NAT, and does not support symmetric NAT. Therefore, you need to identify the NAT behavior on the network before using STUN for NAT. In addition, different NAT types correspond to different NAT mapping and filtering modes.
NAT Mapping and Filtering Modes
The full-cone NAT combines EIM and EIF.
The restricted-cone NAT combines EIM and ADF.
The port-restricted cone NAT combines EIM and APDF.
The symmetric NAT combines APDM and APDF.
To identify the NAT type, a dedicated STUN server with two public IP addresses is required. In this document, assume that the two public IP addresses of the STUN server are A and B, and the corresponding port numbers are a and b, respectively. The private IP address and port number of the STUN client X are X and x, and the NAT-translated IP address and port number are M and m, respectively. For ease of description, two extranet endpoints corresponding to the STUN server are marked as Endpoint (A,a) and Endpoint (B,b), the intranet endpoint of STUN client X as Endpoint (X,x), and the NAT-translated endpoint as Endpoint (M,m). The following describes the process of identifying the NAT mapping type and NAT filtering type.
NAT Mapping Type Identification
- Client X sends a binding request from Endpoint (X,x) to Endpoint (A,a) of the STUN server. The STUN server sends a binding response from Endpoint (A,a) to Endpoint (X,x). The binding response includes the information about the client's NAT-translated Endpoint (M1,m1) and the other extranet Endpoint (B,b) of the STUN server. After receiving the binding response, client X performs the following operations:
If Endpoint (M1,m1) is the same as Endpoint (X,x), client X considers that its private IP address and port number are not translated and ends the process.
If Endpoint (M1,m1) is different from Endpoint (X,x), client X considers that its private IP address and port number are translated and proceeds with the next step.
- Client X sends a binding request from Endpoint (X,x) to Endpoint (B,a). Compared with the operation in step 1, the public IP address of the STUN server is changed from A to B. The STUN server sends a binding response to client X from Endpoint (B,a). The binding response contains the information about the client's NAT-translated Endpoint (M2,m2). After receiving the binding response, client X performs the following operations:
If Endpoint (M2,m2) is the same as Endpoint (M1,m1), EIM is used for NAT mapping because EIM assigns the same public IP address and port number to packets sent from the same private IP address and port number.
If Endpoint (M2,m2) is different from Endpoint (M1,m1), client X proceeds with the next step.
- Client X sends a binding request from Endpoint (X,x) to Endpoint (B,b). Compared with the operation in step 2, the public port number of the STUN server is changed from a to b. The STUN server sends a binding response to client X from Endpoint (B,b). The binding response contains the information about the client's NAT-translated Endpoint (M3,m3). After receiving the binding response, client X performs the following operations:
If Endpoint (M3,m3) is the same as Endpoint (M2,m2), ADM is used for NAT mapping because ADM assigns the same public IP address and port number to the packets sent from the same private IP address and port number and destined to the same public IP address, regardless of the public port number.
If Endpoint (M3,m3) is different from Endpoint (M2,m2), APDM is used for NAT mapping because APDM assigns the same public IP address and port number to the packets sent from the same private IP address and port number and destined to the same public IP address and port number.
NAT Filtering Type Identification
- Client X sends a binding request from Endpoint (X,x) to Endpoint (A,a) of the STUN server. The binding request carries the CHANGE-REQUEST attribute, instructing the STUN server to send the binding response with a different IP address and port number. The STUN server sends a binding response from Endpoint (B,b) to the NAT-translated Endpoint (M,m). Client X performs the following operations based on whether it can receive the binding response:
If a binding response is received, EIF is used for NAT filtering because EIF forwards any packet destined to the NAT-translated Endpoint (M,m) regardless of the source.
If no binding response is received, client X proceeds with the next step.
- Client X sends a binding request from Endpoint (X,x) to Endpoint (A,a) of the STUN server. The binding request carries the CHANGE-REQUEST attribute, instructing the STUN server to send the binding response with a different port number. The STUN server sends a binding response from Endpoint (A,b) to the NAT-translated Endpoint (M,m). Client X performs the following operations based on whether it can receive the binding response:
If so, ADF is used for NAT filtering because if Endpoint (X,x) has sent packets to the extranet endpoint of the STUN server whose IP address is A, the NAT passes any packet sent to Endpoint (M,m) from the STUN server with the IP address A through any port.
If not, APDF is used for NAT filtering because the NAT passes any packet sourced from Endpoint (A,a) to Endpoint (X,x) only if Endpoint (X,x) has sent packets to Endpoint (A,a).
STUN Message Structure
Message Header
All STUN messages must start with a 20-byte header followed by zero or more attributes. The STUN header contains four fields: STUN Message Type, Message Length, Magic Cookie, and Transaction ID, as shown in Figure 5-17.
The most significant 2 bits of every STUN message must be zeroes. This can be used to differentiate STUN messages from other protocol packets when STUN is multiplexed with other protocols on the same port.
STUN Message Type
This field is 14 bits in length. Currently, only STUN binding request messages and STUN binding response messages are supported, of which the values of the STUN Message Type field are 0x0001 and 0x0101 respectively.
Message Length
This field is 16 bits in length, excluding the message header.
Magic Cookie
This field is 32 bits in length and contains the fixed value 0x2112A442. It allows a STUN server to detect if the STUN client will identify certain attributes and aids distinguishing STUN messages from packets of other protocols when STUN is multiplexed with other protocols on the same port.
Transaction ID
This field is a 96-bit identifier, used to uniquely identify a STUN transaction. For request/response transactions, the transaction ID is chosen by the STUN client for the request and echoed by the server in the response. The STUN server also uses the transaction ID to identify each transaction uniquely across all clients.
Message Attributes
The STUN header is followed by zero or more attributes. Each attribute must be Type-Length-Value (TLV) encoded, with a 16-bit type, 16-bit length, and variable-length value. Figure 5-18 shows the format of STUN message attributes.
Table 5-2 lists the currently supported message attributes.
| Attribute (Type) | Value | Description |
|---|---|---|
| MAPPED-ADDRESS | 0x0001 | Post-NAT IP address and port number of a client. This attribute is used only by servers for achieving backward compatibility with RFC 3489 clients. |
| XOR-MAPPED-ADDRESS | 0x0020 | Post-NAT IP address and port of a client. This attribute is identical to the MAPPED-ADDRESS field, except that the IP address is processed by the exclusive OR (XOR) function. |
| RESPONSE-ORIGIN | 0x802b | IP address and port number used by the server to determine whether a NAT device is in front of the server. |
| SOFTWARE | 0x8022 | Software version information. |
| PATHSET | 0xb001 | Huawei extended attribute, which uniquely identifies an EVPN tunnel. |
STUN Implementation
Figure 5-19 shows the STUN message exchange process.
- A STUN client sends a STUN binding request message to a STUN server.
- The STUN server receives the STUN binding request message, obtains the source IP address and source port in the message, and sends a STUN binding response message to the client. The response message carries the MAPPED-ADDRESS, XOR-MAPPED-ADDRESS, and RESPONSE-ORIGIN attributes.
- The STUN client receives the STUN binding response message, obtains an IP address and port number based on the MAPPED-ADDRESS or XOR-MAPPED-ADDRESS attribute in the message, and compares the IP address and port number with the source IP address and port number in the STUN binding request message. If they are different, a NAT device is in front of the STUN client.
- STUN clients use BGP to learn NAT information (pre-NAT and post-NAT IP addresses and port numbers) from each other.
- Client1 uses the local pre-NAT IP address and port number and Client2's pre-NAT IP address and port number to construct a STUN binding request message and sends the message to Client2. In addition, Client1 uses the local pre-NAT IP address and port number and Client2's post-NAT IP address and port number to construct a STUN binding request message and sends the message to Client2. Client2 performs the corresponding operations.
- Client2 receives the STUN binding request message and sends a STUN binding response message to Client1. Client1 performs the corresponding operations.
After the preceding STUN message exchange, STUN clients successfully establish a data channel for NAT traversal.
The DSCP value in the STUN packet is 48.