STUN

What Is STUN?

In a point-to-point (P2P) network, it's crucial for two communicating parties to be able to actively connect with each other. However, this can be hindered by NAT devices, which block direct access and can disrupt the functioning of P2P applications. STUN technology is frequently employed to address this NAT traversal issue. It enables network devices to identify the post-NAT IP addresses and port numbers of communicating parties, enabling the establishment of P2P data channels that can traverse NAT devices for seamless P2P communication.

Why We Need STUN?

NAT is extensively utilized to alleviate the depletion of IPv4 addresses and provides security by filtering out certain packets sent from external networks to the internal network. However, it poses challenges for P2P communication as it doesn't facilitate two P2P communicating parties to initiate access.

To address these issues, various NAT traversal techniques have emerged for P2P networks. These include reverse links, application layer gateway (ALG), hole punching, and middleware techniques. These methods aim to circumvent NAT restrictions and enable seamless P2P communication despite the presence of NAT devices.

The STUN protocol, as outlined in the RFC, serves to identify NAT devices positioned along the communication path between two communicating parties and retrieve the post-NAT IP addresses and port numbers of these parties. Subsequently, it enables the establishment of a P2P channel that can traverse NAT devices for communication, a process commonly known as hole punching. STUN technology is extensively employed due to its compatibility with existing NAT devices, eliminating the need for any modifications, and requiring only one STUN server deployment on the network.

What Is a STUN Server?

STUN operates on the client/server model, comprising both the STUN server and the STUN client:

• STUN server: A router can act as a STUN server, responsible for sending STUN binding responses and receiving STUN binding requests. Typically, the STUN server is deployed on a public network.

• STUN client: A router can operate as a STUN client, tasked with sending STUN binding requests and receiving STUN binding responses.

Within the STUN standard, NAT is categorized into four types based on the mapping method from the private IP address and port to the public IP address and port: full cone NAT, restricted cone NAT, port restricted cone NAT and symmetric NAT. For further information regarding these four NAT types, please refer to the NAT documentation.

How Does STUN Work?

By engaging in a message exchange with a STUN client, a STUN server can identify a NAT device and retrieve the IP address and port number assigned by the NAT device to the STUN client. Following the establishment of a data channel between STUN clients, they gain the ability to access each other. The STUN message exchange process comprises two phases: NAT detection and hole punching. The detailed process is illustrated in the following figure.

NAT Detection

1. 1. Each STUN client initiates a binding request to the STUN server.

2. 2. Upon reception of the binding requests, the STUN server retrieves the source IP addresses and port numbers, subsequently sending a binding response to each STUN client. The binding response message includes attributes such as MAPPED-ADDRESS, XOR-MAPPED-ADDRESS, and RESPONSE-ORIGIN.

3. 3. The STUN client extracts an IP address and port number from the MAPPED-ADDRESS or XOR-MAPPED-ADDRESS attribute within the binding response. It then compares this information with the source IP address and port number provided in the binding request. If a disparity exists, indicating the use of a NAT device in front of the STUN client, the NAT detection process is confirmed. Following this confirmation, each STUN client notifies the service module accordingly.

Hole Punching

Hole punching is a method used to create a direct connection between P2P communicating parties that are situated behind NAT devices. This technique facilitates the establishment of a data channel between P2P STUN clients by traversing intermediate devices, such as RRs, and generating NAT session entries on NAT devices. The process of STUN hole punching unfolds as follows:

1. 1. A STUN client retrieves the TNP information, including IP addresses and port numbers before and after NAT, of other STUN clients from a route reflector (RR) via BGP. When STUN client 1 intends to establish communication with STUN client 2, it dispatches BGP packets to notify STUN client 2 about the necessity for hole punching to set up a data channel.

2. 2. STUN client 1 and STUN client 2 exchange binding requests with each other to facilitate hole punching. STUN client 1 dispatches two binding requests to STUN client 2. Specifically, it transmits message A containing the pre-NAT IP address and port number, and message B containing the post-NAT IP address and port number. STUN client 2 replicates this process.

3. 3. Upon reception of messages A and B, STUN client 2 processes the messages in the following manner. STUN client 1 executes a similar procedure:

• If STUN client 1 and STUN client 2 reside on the same private network, meaning they are behind the same NAT device, message A can be successfully transmitted to STUN client 2. Conversely, if they are not on the same private network, message A is disregarded.

• Subsequent to STUN client 1 transmitting message B, NAT device 1 generates an entry to log the session from STUN client 1 to STUN client 2. However, as NAT device 2 (located in front of STUN client 2) lacks the corresponding session entry, message B is discarded by NAT device 2.

• Concurrently, NAT device 2 creates an entry to log the session from STUN client 2 to STUN client 1. However, since NAT device 1 lacks the corresponding session entry, it discards message B.

• STUN client 1 and STUN client 2 persistently dispatch binding requests to each other. Once session entries are established on both NAT device 1 and NAT device 2, the two STUN clients become capable of receiving binding requests from each other.

• Upon receipt of a binding request from STUN client 1, STUN client 2 transmits a binding response to STUN client 1. Subsequently, STUN client 1 reciprocates the action by sending a binding response to STUN client 2.

Following the exchange of the aforementioned STUN messages, a data channel is established between the STUN clients, facilitating the traversal of packets through the NAT devices.

What Is STUN Used for in SD-WAN?

In an SD-WAN Solution, users at branch sites frequently utilize private IP addresses to connect to the headquarters via NAT, conserving IP address resources. Consequently, branch Customer Premises Equipment (CPEs) are typically equipped with NAT devices. As packets transmitted by branch CPEs traverse the NAT devices, their IP addresses undergo alteration. Failure to obtain the post-NAT IP addresses may lead to the inability to establish the data channel between the CPEs. Therefore, to facilitate service traffic between branches via NAT devices, the deployment of STUN within the SD-WAN scenario becomes imperative.

In the NAT traversal networking, both the Route-Reflector (RR) and branch Customer Premises Equipment (CPEs) initiate registration requests to iMaster NCE via management channels. Upon successful registration, iMaster NCE undertakes the management of both the RR and CPEs. Subsequently, the CPEs disseminate Transport Network Port (TNP) information encompassing details regarding sites, routes, tunnels, and IP addresses alongside port numbers pre- and post-NAT to the RR through the management channels. Simultaneously, they retrieve TNP information concerning another CPE from the RR. Consequently, service traffic between CPE 1 and CPE 2 is facilitated through a data channel.

NAT devices are positioned in front of both CPE 1 and CPE 2. To facilitate service interoperability between CPE 1 and CPE 2, STUN deployment is necessary on both the RR and CPEs to ascertain the presence of a NAT device between the CPEs. Moreover, the RR acquires the post-NAT IP addresses and port numbers of both CPE 1 and CPE 2. This enables the establishment of a data channel between CPE 1 and CPE 2, facilitating the forwarding of service traffic.

Branch CPEs operate as STUN clients, while the RR serves as the STUN server. The interaction process unfolds as follows:

1. 1. A branch CPE initiates a STUN binding request to the RR.

2. 2. The RR responds by transmitting a STUN binding response to the branch CPE.

3. 3. Subsequently, upon receipt of the STUN binding response from the RR, the CPE evaluates whether a NAT device is situated in front of it.

4. 4. Following the detection process, the CPE dispatches its Transport Network Port (TNP) information, encompassing both pre- and post-NAT IP addresses alongside port numbers, to the RR via BGP. Simultaneously, it retrieves the TNP information pertaining to another CPE from the RR.

5. 5. Armed with the acquired TNP information, the CPEs leverage the post-NAT IP addresses and port numbers to initiate the establishment of a data channel, facilitating the transmission of service traffic.