What Is STUN?
A point-to-point (P2P) network requires that two communicating parties be able to proactively access each other. However, NAT devices block the access, thereby affecting normal running of P2P applications. STUN technology is commonly used to overcome this NAT traversal problem. It allows network devices to discover post-NAT IP addresses and port numbers of communicating parties and to use this information to establish P2P data channels traversing the NAT devices for P2P communication.
Why We Need STUN?
NAT is widely deployed to mitigate the exhaustion of IPv4 addresses. It also protects against attacks from external networks by dropping some packets sent from external networks to the internal network. However, it is not suitable for P2P communication, such as a P2P network, since it cannot enable two P2P communicating parties to initiate access.
To solve the problems, some NAT traversal techniques for P2P networks emerge, such as reverse link, application layer gateway (ALG), hole punching, and middleware techniques.
The STUN protocol defined by RFC is used to discover NAT devices located along the path between two communicating parties and to obtain post-NAT IP addresses and port numbers of the communicating parties. Then, a P2P channel traversing NAT devices can be set up between two communicating parties for communication. This process is also called hole punching. The STUN technology is widely used because it works with existing NAT devices and does not require any modification on them, while only one STUN server needs to be deployed on the network.
What Is a STUN Server?
STUN uses the client/server model and consists of the STUN server and STUN client:
- STUN server: A router can function as a STUN server and send STUN binding responses and receive STUN binding requests. The STUN server is usually deployed on a public network.
- STUN client: A router can function as a STUN client and send STUN binding requests and receive STUN binding responses.
Typical STUN networking
In the STUN standard, NAT is classified into four types according to the mapping mode 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 details about the four NAT types, see NAT.
How Does STUN Work?
Through message exchange with a STUN client, a STUN server can discover a NAT device and obtain the IP address and port number allocated by the NAT device to the STUN client. After a data channel is established between STUN clients, the clients can access each other. The STUN message exchange process consists of two phases: NAT detection and hole punching. The following figure shows the detailed process.
STUN message exchange process
- Each STUN client sends a binding request to the STUN server.
- After receiving binding requests, the STUN server obtains the source IP addresses and port numbers and sends a binding response to each STUN client. The binding response message carries the MAPPED-ADDRESS, XOR-MAPPED-ADDRESS, and RESPONSE-ORIGIN attributes.
- The STUN client obtains an IP address and port number from the MAPPED-ADDRESS or XOR-MAPPED-ADDRESS attribute in the binding response, and compares the obtained IP address and port number with the source IP address and port number carried in the binding request. If they are different, a NAT device is used in front of the STUN client. After confirming the NAT detection result, each STUN client notifies the service module of the result.
Hole punching is a technique for establishing a direct connection between P2P communicating parties behind NAT devices. Specifically, it sets up a data channel between P2P STUN clients across intermediate devices (such as RRs) by creating NAT session entries on NAT devices. The process of STUN hole punching is as follows:
- A STUN client obtains the TNP information (including IP addresses and port numbers used before and after NAT) of other STUN clients from an RR through BGP. When STUN client 1 needs to communicate with STUN client 2, it sends BGP packets to notify STUN client 2 that hole punching is required to establish a data channel.
- STUN client 1 and STUN client 2 send binding requests to each other for hole punching. STUN client 1 sends two binding requests to STUN client 2. Specifically, it sends message A containing pre-NAT IP address and port number and message B containing post-NAT IP addresses and port number, and STUN client 2 repeats this process.
- After receiving messages A and B, STUN client 2 processes the messages as follows. STUN client 1 repeats similar process:
- If STUN client 1 and STUN client 2 are on the same private network, that is, behind the same NAT device, message A can be successfully sent to STUN client 2. Otherwise, message A is discarded.
- After STUN client 1 sends message B, NAT device 1 generates an entry to record the session from STUN client 1 to STUN client 2. However, since NAT device 2 (which is in front of STUN client 2) does not have the corresponding session entry, NAT device 2 will discard message B.
- Meanwhile, NAT device 2 also generates an entry to record the session from STUN client 2 to STUN client 1. As NAT device 1 does not have the corresponding session entry either, it will discard message B.
- STUN client 1 and STUN client 2 continuously send binding requests to each other. When session entries are generated on both NAT device 1 and NAT device 2, the two STUN clients can receive binding requests from each other.
- After receiving a binding request from STUN client 1, STUN client 2 sends a binding response to STUN client 1. STUN client 1 does the same.
After the preceding STUN messages are exchanged, a data channel is established between the STUN clients so that packets can traverse the NAT devices.
What Is STUN Used for in SD-WAN?
In the SD-WAN Solution, users at branch sites often use private IP addresses to access the headquarters through NAT to save IP address resources. Therefore, branch CPEs are often deployed together with NAT devices. After packets sent by branch CPEs traverse the NAT devices, the IP addresses change. If the post-NAT IP addresses cannot be obtained, the data channel between the CPEs fails to be established. Therefore, to enable service traffic between branches through NAT devices, you need to deploy STUN in the SD-WAN scenario.
NAT traversal in the SD-WAN Solution
In the NAT traversal networking, an RR and branch CPEs send registration requests to iMaster NCE through management channels. After the registration is successful, the RR and CPEs are managed by iMaster NCE. The CPEs advertise transport network port (TNP) information such as information about sites, routes, tunnels, and IP addresses and port numbers before and after NAT to the RR through the management channels, and obtains TNP information about another CPE from the RR. As such, service traffic between CPE 1 and CPE 2 is transmitted through a data channel.
NAT devices are deployed in front of CPE 1 and CPE 2. To implement service interworking between CPE 1 and CPE 2, STUN needs to be deployed on the RR and CPEs to detect whether a NAT device is deployed between the CPEs. In addition, the RR obtains post-NAT IP addresses and port numbers of CPE 1 and CPE 2. A data channel is established between CPE 1 and CPE 2 for service traffic forwarding.
Branch CPEs function as STUN clients, and the RR functions as the STUN server. The interaction process is as follows:
- A branch CPE sends a STUN binding request to the RR.
- The RR sends a STUN binding response to the branch CPE.
- After receiving the STUN binding response from the RR, the CPE determines whether a NAT device exists in front of the CPE.
- After the detection, the CPE sends its TNP information (including the pre- and post-NAT IP addresses and port numbers) to the RR through BGP and obtains the TNP information of another CPE through the RR.
- After obtaining the TNP information, the CPEs use the post-NAT IP addresses and port numbers to establish a data channel to transmit service traffic.
- Author： Liu Qiaoqiao
- Updated on： 2021-09-30
- Views： 22545
- Average rating：