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 and 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?

NAT technology 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. Essentially, each device connected to the home or business network has a private IP address (e.g., 192.168.1.x, 10.0.0.x), while the router performs address translation to present a single public IP address to the outside world.

This operation is essential for two main reasons:

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

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

However, this very barrier that protects devices introduces a non-trivial challenge: the lack of direct reachability . From the perspective of an external client, a device behind NAT has no unique public identity, and the router doesn't know which host to forward any incoming requests to unless they were 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 must 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 to circumvent 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, firewalls , both at the client and enterprise levels, also come into play. 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 and the port 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 peer-to-peer communication. Hence the importance of the STUN protocol (to discover public identity) and, in more complex cases, 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 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 server . This server responds with the IP address and port from which the request was received, representing 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 discovery tool that helps prepare the ground for subsequent negotiation between peers.

STUN Limits

While STUN is extremely useful, it's not always sufficient. Some types of NAT (especially Symmetric NAT ) and particularly restrictive firewalls prevent direct connections altogether. In these cases, peer-to-peer communication fails, and a fallback mechanism is needed: 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 RFC 5766 and represents the evolution of the STUN protocol, offering a reliable solution under 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 requests a resource allocation (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 only used 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) that tests various “candidate” connections between the peers:

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

2. Server reflexive candidates : connections obtained via STUN.

3. Relay candidates : connections via TURN servers.

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 STUN/TURN implementations, it is impossible not to mention coturn , the most widespread and supported open source project in this field.

What is coturn?

Coturn is 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 mature open source project that has been used for years in production environments, including large VoIP systems, video conferencing platforms, multiplayer games, and real-time collaboration tools. Its operational stability 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) , ensuring a high level of interoperability with WebRTC, SIP, and VoIP libraries and clients. This means it can be easily integrated into heterogeneous environments, without the need for workarounds or customizations. It supports both the STUN and TURN protocols , as well as advanced features such as 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-scale enterprise solutions . The ability to integrate logging and monitoring systems (e.g., via syslog or prometheus-exporter) allows it to be kept under control even in mission-critical environments.

🔐 Safety

Security is a key aspect 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. Furthermore, 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 remains the ideal choice for those who need a professional solution to overcome the limitations imposed by NAT 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 foundation 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

Using the STUN and, especially, TURN protocols involves a series of risks and security implications that should not be underestimated, especially in production settings or in environments publicly exposed on the Internet. TURN, in particular, acts as a relay for traffic between two peers , exposing your infrastructure to potential abuse if not properly protected.

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

Because a TURN server can forward traffic to and from remote peers , it can be leveraged as a bridge for:

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

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

• Data exfiltration or unauthorized communications.

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

✅ Authentication and access management

To prevent abuse, it's essential that TURN servers are protected by a robust authentication system . TURN natively supports authentication:

• Long-term : with pre-configured static credentials.

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

Using the TURN REST API is now highly recommended , as it allows you to temporally and granularly limit access to legitimate clients.

Additionally, you can:

• Restrict access to specific IP ranges.

• Set timeouts and bandwidth limits per session.

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

• Enable 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 peer-to-peer communications.

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 provides all the tools needed 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

Careful and informed configuration helps mitigate risks and protect the infrastructure from abuse or external attacks. It's crucial 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 is not “plug and play” : implementation must be accompanied by technical, organizational, and procedural security measures.

Coturn , when configured correctly, represents a reliable, safe and highly controllable solution , 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're considering installing and configuring a TURN/STUN server for your infrastructure, we at MANAGED SERVER SRL have extensive experience implementing and managing TURN-based servers . We can help you design a scalable, secure, and high-performance solution tailored to your specific use case.