STUN Server: what it is, how it works and where it is used

What is a STUN Server

STUN Server (Session Traversal Utilities for NAT) is a network service operating on the protocol defined in RFC 5389 and updated in RFC 8489. The main task of a STUN server is to provide a client with information about its own public IP address and port as seen from the external network, as well as to determine the type of NAT device between the client and the internet.

The STUN architecture includes two components: a STUN client embedded in the application (e.g., a browser or native WebRTC application) and a STUN server deployed in the public network. The client sends a STUN Binding Request to the server, which in its response indicates the source IP address and port of the request — that is, the public addresses of the client as seen by the server. By comparing this data with its local addresses, the client can determine which type of NAT is being used in its network.

STUN Protocol

STUN operates over UDP (port 3478 by default) or TCP (port 3478 or 5349 for TLS). A STUN message consists of a 20-byte header and a variable number of attributes. The header contains the message type (Binding Request, Binding Response, Binding Error Response), length, and a unique transaction ID (96 bits) that allows matching requests and responses. Each Binding Response contains the XOR-MAPPED-ADDRESS attribute — the client's external address, encoded with masking to protect against attacks based on STUN traffic interception.

How a STUN server works

A STUN server operates on a simple request-response protocol. A client behind NAT creates a Binding Request and sends it to the STUN server. The server receives the packet, extracts the source IP address and sender port from the UDP header, then creates a Binding Response, packaging this address into the XOR-MAPPED-ADDRESS attribute. The response is sent back to the request's source address.

The client receives the response and extracts the XOR-MAPPED-ADDRESS, which contains the external IP address and port assigned by the NAT device. The client then compares this address with its local (RFC 1919 — private) address. If the addresses match — the client is not behind NAT. If they differ — the client is behind NAT, and the external address is used as a candidate for ICE (Interactive Connectivity Establishment) in WebRTC.

NAT Discovery Process

A STUN server allows determining the NAT type through a sequence of test requests. The client sends requests with different flags (CHANGE-REQUEST) and analyzes the responses. The full discovery cycle includes sending requests to different IP addresses and ports of the STUN server. If the server responds to a request with a changed port — the NAT is of Restricted Cone type. If it does not respond to a request with a changed port and IP — the NAT is of Symmetric NAT type. This information is critical for choosing the ICE strategy in WebRTC.

STUN server and NAT types

A STUN server can detect four main types of NAT, each of which affects the ability to establish a P2P connection differently. The NAT type determines whether STUN can enable a direct connection between two clients. The NAT type determines which ICE candidate — host, server reflexive, or relay — will be used for the connection.

Symmetric NAT is the only type with which STUN cannot cope. With Symmetric NAT, each new request to a new destination host gets a different external address (IP and/or port). Since the STUN server reports the address for the connection to the STUN server itself, this address is unsuitable for connecting to another client. In such cases, WebRTC uses a TURN server to relay traffic. According to research (Ford et al., RFC 3489, 2003), about 8–10% of all NAT devices on the internet are symmetric.

Using STUN server in WebRTC

A STUN server is integrated into WebRTC through the RTCPeerConnection configuration. A browser or native application uses STUN to collect ICE candidates, which are then exchanged via the Signaling Server. In the WebRTC configuration, the STUN server is specified in the iceServers array with the stun: prefix for UDP or stuns: for TLS connections.

Let us consider an example of setting up a STUN server in JavaScript when creating an RTCPeerConnection for a WebRTC application.

const config = {
    iceServers: [
        {
            urls: "stun:stun.l.google.com:19302"
        },
        {
            urls: "stun:stun1.l.google.com:19302"
        }
    ]
};

const pc = new RTCPeerConnection(config);

pc.onicecandidate = (event) => {
    if (event.candidate) {
        console.log("ICE candidate:", event.candidate.candidate);
    }
};

const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

This example uses Google's public STUN servers (stun.l.google.com:19302). When creating an offer or answer, the browser automatically sends a STUN Binding Request to the specified servers, receives the external address (server reflexive candidate), and adds it to the list of ICE candidates. After all candidates are collected, they are sent to the remote peer via the Signaling Server to attempt establishing a direct P2P connection.

ICE Candidate Types and STUN

In the ICE process, there are three candidate types: host (local address), srflx (server reflexive — obtained from STUN), and relay (relayed through TURN). The STUN server enables the creation of srflx candidates, which have a higher priority than relay candidates because a STUN-based connection is direct and does not require relaying. The ICE process checks all candidate combinations (local and those obtained from STUN) of both peers, starting with the highest priorities.

Limitations of the STUN protocol

A STUN server has fundamental limitations related to the protocol architecture. The main limitation is the inability to work with Symmetric NAT, where each new request to an external host gets a unique external port. In this case, the address obtained from the STUN server cannot be used to connect to another peer because the NAT created a binding only for communication with the STUN server itself.

The second limitation is that STUN does not provide data relay. If direct P2P connection is impossible (both peers behind Symmetric NAT), STUN does not offer an alternative path for data transmission. In this case, a TURN server is required, which acts as a media traffic relay between peers, receiving data from one participant and sending it to another through its public IP address.

• Symmetric NAT — STUN does not work with symmetric NAT because the external address is unique for each destination host and cannot be reused for P2P.
• Firewall Deep Packet Inspection — some firewalls block STUN traffic by detecting protocol signatures in UDP packets on port 3478.
• IPv6 — in IPv6 networks, NAT is typically not used, so STUN is not required, but WebRTC on IPv6 can use host candidates without needing STUN or TURN.
• Availability dependency — the STUN server must be accessible to the client during the connection setup phase, otherwise srflx candidates will not be collected.
• Security — the STUN protocol is vulnerable to amplification attacks if the server is misconfigured and responds to requests with a spoofed source address.

Despite the limitations, a STUN server remains a critical component of the WebRTC infrastructure. In most cases (80–90%), a direct P2P connection can be established using STUN, which avoids the costs of TURN relay and reduces media data transmission latency. For public WebRTC applications, it is recommended to use a combination of STUN and TURN servers with automatic fallback.