TURN/STUN Server: What is it and what is it used for?

Understanding real-time communication on the Internet

In recent years, the number of applications requiring real-time communication has grown exponentially. Video conferencing platforms, remote collaboration tools, VoIP services, online gaming, monitoring systems, IoT devices, and even telemedicine applications all require the ability to transmit audio, video, and data in real time, with minimal latency and high reliability.

However, establishing direct communication between two devices over the Internet is far from trivial, especially due to NAT (Network Address Translation) and firewalls that protect private networks. This is where two fundamental protocols come into play: STUN e TURN.

The NAT traversal problem

To understand the usefulness of the STUN and TURN protocols, it is essential to first analyze the main obstacle that hinders peer-to-peer communications on the modern Internet: the so-called NAT traversal, or overcoming the barriers imposed by NAT (Network Address Translation).

What is NAT and why is it used?

The technology NAT It is widely used in routers and network gateways to allow multiple devices within a local area network (LAN) to share a single public IP address. In practice, each device connected to the home or business network has a private IP (e.g., 192.168.1.x, 10.0.0.x), while the router performs address translation to present a single public IP to the outside world.

This operation is essential for two main reasons:

• Saving IPv4 addresses: Available IPv4 addresses are limited, and NAT allows them to be reused internally.

• Safety: Devices behind NAT are not directly reachable from the Internet, which reduces exposure to external attacks.

However, this very barrier that protects the devices introduces a non-trivial challenge: the lack of direct accessibilityFrom the perspective of an external client, a device behind NAT does not have a unique public identity, and the router does not know which host to forward any incoming requests to unless they have been preceded by an outgoing connection (as in the case of an HTTP request).

Why is this a problem in peer-to-peer communications?

This limitation is particularly problematic for applications that rely on peer-to-peer (P2P) connections, i.e., direct connections between two devices, without passing through intermediate servers. Typical examples include:

• VoIP (Voice over IP) services, such as SIP or IP phones

• Video conferencing platforms

• WebRTC applications like Google Meet, Jitsi, Discord, etc.

• Remote desktop software

• Multiplayer games with P2P logic

• IoT and smart home devices that need to send or receive commands in real time

In these cases, both parties must be able to reach each other, and therefore need to know each other's public IP addresses and communication ports. However, if both devices are behind different NATs (a very common case these days), a direct connection becomes impossible without a mechanism that circumvents this obstacle.

The complexities of different NAT types

To further complicate matters, not all NATs behave the same way. There are different types of NATs, each with different characteristics and levels of restriction:

• Full Cone NAT: Once a mapping between the internal and public IP/port is established, any host can send packets to that public address and they will be forwarded to the internal client. This is the most permissive.

• Restricted Cone NAT: Only external hosts that have received packets from the client can send data to it.

• Port Restricted Cone NAT: like the previous one, but the restriction is also applied on the remote port.

• Symmetric NAT: Creates a new mapping for each outgoing connection to a remote host. This is the most restrictive and the main enemy of P2P communications.

Applications must account for these variables and adapt dynamically. However, without supporting tools like STUN and TURN, direct communication is often impossible.

The further obstacle of firewalls

To make matters worse, the following also come into play: firewall, both at the client and enterprise level. A firewall can block incoming or outgoing connections on specific ports, preventing peer-to-peer traffic from flowing. Some firewalls are configured to block all UDP traffic, the preferred protocol for real-time communications, making connection stability even more difficult.

The need to “discover” one's public identity

For two peers to establish a direct connection, they must know "who they are" from the Internet's perspective. In other words, a device must know the public IP address e the door to which the router has mapped its communication. However, there is no native way in browsers or operating systems to obtain this information.

Hence the need for tools and protocols that provide this type of insight and facilitate communication between peers. Hence the importance of the protocol. STUN (to discover the public identity) and, in the most complicated cases, of the TURN protocol (to report data via a third-party server).

STUN: the first step towards direct connection

What is STUN?

STUN, Short for Session Traversal Utilities for NAT, is a lightweight and simple protocol that allows a device to determine its public IP address and the nature of the NAT protecting it. STUN is described in the RFC 5389 and is designed to allow applications to discover how they are seen from outside their network.

How does STUN work?

When a client wants to establish a connection with another peer, it sends a STUN request to a public STUN serverThis server responds with the IP address and port from which the request was received, which represent the client's public identity. This information can then be shared with the other peer, hoping that both can establish a direct connection.

The STUN protocol does not establish the connection itself, but is a means of discovery useful for preparing the ground for subsequent negotiation between peers.

STUN Limits

While STUN is extremely useful, it is not always sufficient. Some NAT types (particularly Symmetric NAT) and particularly restrictive firewalls prevent direct connections in any case. In these cases, peer-to-peer communication fails, and a fallback mechanism is needed: and this is where TURN comes in.

TURN: the secure channel for every eventuality

What is TURN?

TURN, Short for Traversal Using Relays around NAT, is a protocol that allows a client to send and receive data through a relay server located on the Internet. TURN is defined by the RFC 5766 and represents the evolution of the STUN protocol, offering a reliable solution in any network conditions.

Simply put, when direct connection between peers isn't possible, TURN acts as an intermediary, receiving packets from one peer and retransmitting them to the other. This ensures that communication can occur transparently, even if both devices are behind complicated NATs or restrictive firewalls.

How does TURN work?

The client contacts the TURN server and requires the allocation of a resource (an IP/port pair). Once allocated, the client can use this public endpoint to receive packets from other peers. When a peer sends a packet to that address, the TURN server forwards it to the actual client, acting as a relay.

TURN, unlike STUN, consumes more network resources because all traffic passes through the TURN server. This introduces increased latency and significant bandwidth consumption, which is why TURN is used. only as a last resort, when STUN fails.

STUN and TURN in the WebRTC context

WebRTC (Web Real-Time Communication) is a technology that allows browsers to communicate in real time using video, audio, and data. It is used by services such as Google Meet, Zoom, Jitsi, Discord, and many others. WebRTC natively implements the STUN and TURN protocols as part of its connection architecture.

During the negotiation between two peers (the “signaling” phase), WebRTC uses a process called ICE (Interactive Connectivity Establishment) which tests various “candidate” connections between peers:

1. Host candidates: direct connections on the local network.

2. Server reflexive candidates: connections obtained via STUN.

3. Relay candidates: connections via TURN server.

The ICE algorithm dynamically selects the most efficient path. Only if the first two options fail does WebRTC use TURN.

Coturn: The de facto standard for open source STUN/TURN servers

When talking about practical implementations of STUN/TURN, it is impossible not to mention coturn, the most widespread and supported open source project in this field.

What is coturn?

Coturn It's an IETF standards-compliant TURN/STUN server, written in C and actively maintained on GitHub. It supports both STUN and TURN, as well as advanced features such as:

• Username/password based authentication

• Support for TLS/DTLS

• IPv4 ↔ IPv6 Proxying

• Support for TCP and UDP connections

• Integration with external authentication systems

Coturn is used in numerous professional projects, both in self-hosted environments and cloud infrastructures, and is often the backend for real-time communication capabilities on a global scale.

Why choose coturn?

(I.e. Proven Reliability

Coturn is a project mature open source, used for years in production environments, including large VoIP systems, video conferencing platforms, multiplayer games and real-time collaboration tools. Its operational stability It has been extensively tested in high-traffic scenarios and over unreliable internet connections. Thanks to an active development cycle and a knowledgeable community, any relevant bugs are quickly fixed. It is compatible with a wide range of clients and does not suffer from the instabilities common to some alternative implementations.

🌐 Compatibility

Coturn is fully compliant with IETF specifications (RFC 5389, RFC 5766, RFC 5780, RFC 6062, RFC 6156), which ensures a high level of interoperability with WebRTC, SIP, and VoIP libraries and clients. This means it can be easily integrated into heterogeneous environments, without having to resort to workarounds or customizations. It supports both protocols STUN that TURN, as well as advanced features like TURN-over-TLS, STUN with long-term authentication, and TCP allocations.

🚀 Scalability

Coturn is designed to handle heavy loads: thanks to its multithreaded architecture and efficient use of system resources, it can support hundreds or thousands of simultaneous connections. It can be deployed behind a load balancer or configured to run in clusters, making it suitable for both small projects and large large-scale enterprise solutionsThe ability to integrate logging and monitoring systems (e.g., via syslog or prometheus-exporter) allows you to keep it under control even in mission-critical environments.

🔐 Safety

Security is one of the fundamental aspects of coturn: it supports long-term authentication, TLS/DTLS for stream encryption, IP restrictions, filters to prevent server abuse (e.g., unauthorized proxying), and can be configured to operate only in restricted environments or behind VPNs. Additionally, precise restrictions can be enabled to prevent misuse by third parties, reducing the risk of relay abuse or DoS attacks.

For all these reasons, coturn is the recommended choice for anyone looking to implement a professional NAT traversal solution.

For all these reasons, coturn is confirmed ideal choice For those who need a professional solution to overcome the limitations imposed by NATs and firewalls, especially in WebRTC and VoIP contexts. It's free, highly configurable, stable even under heavy load, and supported by a skilled technical community. Whether you're developing a video conferencing application, a messaging system, or a multiplayer platform, coturn represents a solid pillar on which to build.

Real-world use scenarios

Let's see some concrete examples where STUN and TURN are fundamental:

1. Corporate video conference

A videoconferencing platform must ensure that two users, even behind different corporate firewalls, can communicate seamlessly. STUN will attempt to facilitate a direct connection, but if that fails, TURN will still ensure communication via relay.

2. Remote assistance app or remote desktop

Tools like AnyDesk, TeamViewer, or IT helpdesk services must be able to establish a connection even in restrictive networks. Fallback to TURN allows remote access even in the most complicated cases.

3. Peer-to-peer multiplayer video games

Many online games use peer-to-peer logic to reduce the load on central servers. With STUN, clients can discover their public IP address and attempt direct connections. If this isn't possible, TURN still ensures the connection.

4. IoT and smart devices

Devices such as IP cameras, smart intercoms, or smart sensors need to communicate in real time with mobile apps. STUN and TURN enable this communication even when devices are behind NAT.

Security considerations

The use of protocols STUN and especially TURN involves a series of risks and security implications which should not be underestimated, especially in production settings or in environments exposed publicly on the internet. TURN, in particular, acting as traffic relay between two peers, exposes its infrastructure to potential abuse if not properly protected.

⚠️ TURN and risk of abuse (DDoS, unauthorized relay)

Since a TURN server can forward traffic to and from remote peers, can be used as a bridge for:

• Reflexive DDoS attacks, where traffic is routed through TURN to mask the origin of the attack.

• Bandwidth abuse, by malicious clients who use the relay to bypass geographic restrictions or firewalls.

• Data exfiltration or unauthorized communications.

Without one strict authentication, anyone who knows the server's IP can try to use it as a free relay.

✅ Authentication and access management

To prevent abuse, it is essential that TURN servers are protected by a robust authentication systemCoturn natively supports authentication:

• Long term: with pre-configured static credentials.

• Dynamics (TURN REST API): which generates temporary tokens signed with HMAC and expiration, especially useful for WebRTC environments.

The use of the TURN REST API is today Highly recommended, as it allows you to temporarily and granularly limit access to legitimate clients.

Additionally, you can:

• Restrict access to specific IP ranges.

• Setting up timeout e bandwidth limits per session.

• Integrate systems of rate limiting to protect against massive or automated connections.

• Enable the full logging of TURN allocations, useful for detecting suspicious behavior or investigating anomalies.

🔒 Using TLS and DTLS

Communications protection must occur not only at the application level, but also at the transport level. Coturn supports:

• TURN over TLS (TCP+TLS)

• TURN over DTLS (UDP+DTLS)

• STUN over TLS/DTLS

These modes encrypt signaling and media streams, preventing interception by third parties and improving the privacy and integrity of communications between peers.

The use of TLS/DTLS is particularly recommended in sensitive contexts, where peers are located on untrusted networks (e.g., public Wi-Fi, mixed enterprise environments, WebRTC sessions).

🛡️ A secure setup with coturn

Coturn makes available all the necessary tools To implement a secure TURN infrastructure:

• Dynamic authentication with expiration

• IP Filtering and Allocation Control

• TLS and DTLS support

• Detailed logging for auditing and diagnostics

• Ability to run the service with limited privileges

An careful and conscious configuration It helps mitigate risks and protect the infrastructure from abuse or external attacks. It's essential to include security early in the design process, not as a later, corrective measure.

The adoption of STUN and TURN is essential to ensure direct communication in NAT traversal scenarios. However, it's not “plug and play”: it is necessary to accompany the implementation with technical, organizational and procedural security measures.

Coturn, if configured correctly, represents a solution reliable, safe and highly controllable, perfect for environments where safety is not an option but a requirement.

Conclusion

The STUN and TURN protocols are key components for enabling real-time communications on the Internet. STUN enables public address discovery and direct connection negotiation, while TURN provides a fallback solution in even the most complex scenarios.

Without these protocols, technologies like WebRTC simply wouldn't work in many real-world environments. This is precisely why, when designing VoIP, video conferencing, or peer-to-peer communications services, it's essential to deploy reliable, secure, and high-performance STUN/TURN servers.

If you are considering installing and configuring a TURN/STUN server for your infrastructure, We at MANAGED SERVER SRL have a consolidated experience in the implementation and management of servers based on coturnWe can help you design a scalable, secure, and high-performance solution tailored to your specific use case.