What is a Stun server?

The direct peer to peer communication is often blocked by NATs that is Network Address translation, NATs hide device IP addresses behind the routers and for security and IP management. This creates a challenge to create a direct peer-to-peer connection between devices. The STUN servers provide a solution by letting devices learn their own public IP addresses and port numbers as seen by external networks This article is going to explain What is a STUN server? Why is it necessary? How it works and its important role in enabling modern technologies like WebRTC and VoIP What is Network Address Translation (NAT)? What is NAT? NAT maps multiple private IP address inside a local or private network to a single IP address. NATs are basically a workaround, that was invented to preserve limited IPv4 address space. they also come with a basic firewall by default, thus unsolicited inbound traffic is automatically blocked How NAT breaks down connections? The crux of the problem with NAT is that the traffic coming from public networks do not know which internal device to connect to and gets dropped by the NAT device (router). For real time apps that rely heavily on UDP — which is chosen for its low latency and simplicity- this becomes a major issue because UDP is stateless. Without a persistent session or explicit NAT mappings the UDP packets just get dropped Introducing STUN STUN — Session Traversal Utilities for NAT — is a protocol that was designed to help devices that are behind NAT to discover their own public facing IP address and port number. Whenever a client wants to establish a peer-to-peer connection, it first contacts a STUN server on the internet, the STUN server then simply reflects back the observed IP address and port number back to the client This lets the client know what its public IP address and port number is. The client can then use this information to create a direct connection with another client on the internet. What STUN does not do? The important thing to understand is what the STUN does not do. It does not route, relay or carry media or signalling traffic between peers STUN just provides address discovery. If the direct peer to peer connection fails because of symmetric NAT or firewall rules then a different mechanism called TURN (Traversal Using Relays around NAT) must step in to relay the actual traffic. TURN Servers Metered Global TURN servers Metered Global TURN Servers Powerful API: Manage TURN servers, credentials, users, and usage data programmatically. Global Geo-Location Targeting: Routes traffic to the nearest server for optimal performance. Worldwide Servers: 57 regions including Toronto, Miami, San Francisco, Amsterdam, London, Frankfurt, Bangalore, Singapore, Sydney. Low Latency: Under 30ms globally. Cost-Effective: Pay-as-you-go with discounts. Reliability: 99.999% The Metered.ca also offers a free turn server called the openrelayproject.org How STUN server works The binding Request The process starts when the client sends a binding request to a known STUN server, this is usually over UDP for speed and simplicity, although TCP is also an option when reliability and NAT behaviour demands. This is very lightweight because it just asks the server for the clients public IP address and reports back to the client Server Observation When the binding request hits the STUN server, the server observes the source IP address and the port number the packet is originating from, this is basically the public mapping chart the client devices NAT has created for the outbound traffic. Client Learning its address When the client receives the binding response from the STUN server, the client learns its reflexive transport address — — that is the public IP/port combination assigned by NAT. This information can be used to start a direct peer to peer connection, assuming the NAT traversal is possible on the NAT type otherwise you need a TURN server. STUN and UDP Hole Punching The information that is obtained from STUN — each client’s public IP address and port — which is important for enabling peer-to-peer connections in NAT environments. This is because once each client device knows its own public IP and port number, it can then exchange it with another client on the internet with which it wants to establish a connection. The client does this with the help of a signalling server. Once both the client’s have exchanged the Ip address and port number then they engage in UDP hole punching Here is how UDP hole punching works: Each peer starts sending UDP packets to other devices IP address and port number, simultaneously. although initial packets are dropped, the outgoing traffic form each device causes their respective NATs to open up temproray mappings, thus effectively punching a hole Since most

Apr 29, 2025 - 22:37

The direct peer to peer communication is often blocked by NATs that is Network Address translation, NATs hide device IP addresses behind the routers and for security and IP management.

This creates a challenge to create a direct peer-to-peer connection between devices. The STUN servers provide a solution by letting devices learn their own public IP addresses and port numbers as seen by external networks

This article is going to explain

What is a STUN server?
Why is it necessary?
How it works and its important role in enabling modern technologies like WebRTC and VoIP

What is Network Address Translation (NAT)?

What is NAT?

NAT maps multiple private IP address inside a local or private network to a single IP address.

NATs are basically a workaround, that was invented to preserve limited IPv4 address space. they also come with a basic firewall by default, thus unsolicited inbound traffic is automatically blocked

How NAT breaks down connections?

The crux of the problem with NAT is that the traffic coming from public networks do not know which internal device to connect to and gets dropped by the NAT device (router).

For real time apps that rely heavily on UDP — which is chosen for its low latency and simplicity- this becomes a major issue because UDP is stateless.

Without a persistent session or explicit NAT mappings the UDP packets just get dropped

Introducing STUN

STUN — Session Traversal Utilities for NAT — is a protocol that was designed to help devices that are behind NAT to discover their own public facing IP address and port number.

Whenever a client wants to establish a peer-to-peer connection, it first contacts a STUN server on the internet, the STUN server then simply reflects back the observed IP address and port number back to the client

This lets the client know what its public IP address and port number is. The client can then use this information to create a direct connection with another client on the internet.

What STUN does not do?

The important thing to understand is what the STUN does not do. It does not route, relay or carry media or signalling traffic between peers

STUN just provides address discovery. If the direct peer to peer connection fails because of symmetric NAT or firewall rules then a different mechanism called TURN (Traversal Using Relays around NAT) must step in to relay the actual traffic.

TURN Servers

Metered Global TURN servers

Metered Global TURN Servers

Powerful API: Manage TURN servers, credentials, users, and usage data programmatically.
Global Geo-Location Targeting: Routes traffic to the nearest server for optimal performance.
Worldwide Servers: 57 regions including Toronto, Miami, San Francisco, Amsterdam, London, Frankfurt, Bangalore, Singapore, Sydney.
Low Latency: Under 30ms globally.
Cost-Effective: Pay-as-you-go with discounts.
Reliability: 99.999%

The Metered.ca also offers a free turn server called the openrelayproject.org

How STUN server works

The binding Request

The process starts when the client sends a binding request to a known STUN server, this is usually over UDP for speed and simplicity, although TCP is also an option when reliability and NAT behaviour demands.

This is very lightweight because it just asks the server for the clients public IP address and reports back to the client

Server Observation

When the binding request hits the STUN server, the server observes the source IP address and the port number the packet is originating from, this is basically the public mapping chart the client devices NAT has created for the outbound traffic.

Client Learning its address

When the client receives the binding response from the STUN server, the client learns its reflexive transport address — — that is the public IP/port combination assigned by NAT.

This information can be used to start a direct peer to peer connection, assuming the NAT traversal is possible on the NAT type otherwise you need a TURN server.

STUN and UDP Hole Punching

The information that is obtained from STUN — each client’s public IP address and port — which is important for enabling peer-to-peer connections in NAT environments.

This is because once each client device knows its own public IP and port number, it can then exchange it with another client on the internet with which it wants to establish a connection.

The client does this with the help of a signalling server. Once both the client’s have exchanged the Ip address and port number then they engage in UDP hole punching

Here is how UDP hole punching works:

Each peer starts sending UDP packets to other devices IP address and port number, simultaneously. although initial packets are dropped, the outgoing traffic form each device causes their respective NATs to open up temproray mappings, thus effectively punching a hole

Since most NATs allow the return traffic from the destination of an outbound packet, once both of these NATs have holes subsequent packets flow freely, thus enabling a direct connection.

This technique however does not work with all kinds of NATs because. Symmetric NATs a type of NAT the has mappings based on the destination and changes frequently making hole punching unreliable and a TURN server must be used for making a connection.

Limitations of STUN

While STUN is lightweight and effective in many NAT scenarios, it is important to understand its limits — especially when you need systems that are reliable

Here are some of the cases where STUN does not work, this is not a comprehensive list but just to give you an idea.
Symmetric NAT

STUN does not work with symmetric NATs

Here the STUN server provides a public IP and port number for each new request.

The IP address and port number provided to the STUN server by NAT will be different to when it provides a new IP address and port number combo when communicating with any other device on the internet

Thus for every internal device its public IP and port number keeps changing with different connections.

Firewall

even if the NAT is of compatible type, there are restrictive firewalls — in enterprise or carrier grade-may block incoming UDP traffic or allow it only in specific ports. STUN does not work in these scenarios.

Here you need TURN servers to work, you can get TURN servers with metered.ca TURN servers

TURN Servers

When STUN servers fail, this is due to symmetric NATs, firewall rules or any other factors then TURN (Traversal using Relays around NAT) becomes essential

TURN is a full relay server for both signalling and media traffic. Here is how it works

A client allocates a relay address on the TURN server
Instead of sending media directly to the other device, the client sends the data to the TURN server which in turn relays the data to the other device across the internet.

This guarantees connectivity, thus you need TURN servers for reliable connectivity

TURN is part of ICE the Interactive Connectivity Establishment framework. ICE will first try direct paths using STUN and if that fails it will fall back to TURN

This strategy is how the ICE framework works.