Port 3478: STUN — The Mirror at the Edge of the Network

Port 3478 is where devices go to find themselves. It carries STUN traffic, the protocol that answers the most fundamental question in peer-to-peer networking: "What do I look like from the outside?"

Every video call you make, every WebRTC connection your browser establishes, every real-time collaboration tool that connects you directly to another person begins here, at this port, with a device asking a server on the public Internet to describe what it sees.

What STUN Does

STUN stands for Session Traversal Utilities for NAT.¹ The name tells you exactly what it does: it helps traffic traverse the Network Address Translators that stand between private networks and the public Internet.

Here is the problem STUN solves. Your laptop has an IP address, something like 192.168.1.42. That address is private. It means nothing to the outside world. When your packets leave your home network, your router performs Network Address Translation, rewriting the source address to your router's public IP and mapping your internal port to an external one.

Your device has no idea this happened. It still thinks it lives at 192.168.1.42:5000. But to the rest of the Internet, you appear as something like 203.0.113.40:49152.

This creates an existential crisis for peer-to-peer communication. If you want to tell someone else on the Internet how to reach you, what address do you give them? You do not know your own public face.

STUN provides the mirror. A STUN server sits on the public Internet, waiting. You send it a binding request. It looks at the packet that arrives, sees the source address and port as they appear after NAT translation, and sends that information back to you.²

Now you know what you look like from the outside. You can share that address with the person you want to connect to.

How the Protocol Works

The STUN protocol is elegant in its simplicity. A client sends a Binding Request to a STUN server. The server responds with a Binding Response containing the client's reflexive transport address, the IP and port as observed by the server.³

The response uses XOR obfuscation to encode the address. This is not for security. It exists because some NAT devices perform deep packet inspection and rewrite IP addresses they find in packet payloads. By XORing the address with a known value, STUN prevents these overzealous middleboxes from mangling the response.⁴

STUN typically runs over UDP. Since UDP provides no reliability guarantees, STUN clients handle retransmission themselves, backing off exponentially if no response arrives.

The protocol also supports connectivity checks. Two endpoints that have exchanged their public addresses can send STUN packets to each other to verify that a direct path exists. These checks form the foundation of ICE, the Interactive Connectivity Establishment protocol that orchestrates the full NAT traversal dance.⁵

The History

The NAT problem emerged in the late 1990s as IPv4 address exhaustion became real. Network Address Translation conserved addresses by letting entire networks hide behind a single public IP. But it broke a fundamental assumption of the original Internet: that every host has a globally reachable address.

This created chaos for Voice over IP. SIP phones behind NAT would signal their private addresses, resulting in one-way audio or failed calls. Online games struggled to let players host matches. File sharing protocols could not establish direct connections.

In 2001, Jonathan Rosenberg at dynamicsoft began drafting what would become STUN.⁶ The initial concept was to codify the tricks that proprietary protocols had already developed, turning ad-hoc solutions into an interoperable standard.

RFC 3489, published in March 2003, defined "Simple Traversal of UDP Through NATs."⁷ The original specification was ambitious. It attempted to classify NAT types (Full Cone, Restricted Cone, Port Restricted Cone, Symmetric) and promised that clients could determine their NAT type and work around it.

Experience proved this approach flawed. NAT behavior was too varied, too unpredictable. The classification scheme did not map cleanly to reality. Addresses learned through STUN "were sometimes usable and sometimes not, with no way to discover whether it would work."⁸

RFC 5389, published in October 2008, represented a fundamental rethinking.⁹ The authors, including Rosenberg along with R. Mahy, P. Matthews, and D. Wing, renamed the protocol "Session Traversal Utilities for NAT" and repositioned it as a tool rather than a complete solution. STUN would no longer promise to solve NAT traversal on its own. Instead, it would provide building blocks for higher-level protocols like ICE.

RFC 8489, published in February 2020, obsoleted RFC 5389 with further refinements.¹⁰

The Ecosystem: STUN, TURN, and ICE

STUN alone cannot solve NAT traversal. It can tell you your public address, but that address only works if the NAT creates a mapping that other hosts can use. Symmetric NATs, common in corporate networks, assign different external ports for different destinations. The port a STUN server sees is not the port your peer will see.¹¹

When STUN fails, TURN (Traversal Using Relays around NAT) provides the fallback. A TURN server allocates a relay address and forwards all traffic between peers. It is expensive, bandwidth-intensive, and adds latency, but it always works.¹² TURN servers also listen on port 3478 by default.

ICE orchestrates the dance. It gathers candidates from multiple sources: host candidates (local addresses), server reflexive candidates (learned from STUN), and relayed candidates (allocated by TURN). It tests connectivity between all candidate pairs, in priority order, until it finds a path that works. ICE prefers direct connections, falling back to relay only when necessary.¹³

This layered approach powers WebRTC. When you join a video call in your browser, ICE runs invisibly in the background, gathering candidates, exchanging them through the signaling server, and testing paths until your video flows directly to your peer, or through a relay if it must.

Security Considerations

STUN's simplicity creates vulnerabilities. Because it runs over UDP and responds with amplified data, STUN servers can be weaponized for DDoS reflection attacks. Researchers have identified approximately 75,000 abusable STUN servers in the wild, with an amplification factor of 2.32 to 1.¹⁴

While the amplification is modest compared to protocols like DNS or NTP, it still enables attacks. Adversaries have launched single-vector STUN attacks as large as 441 Gbps. The attacks are harder to mitigate because STUN traffic looks similar to legitimate WebRTC connectivity checks.¹⁵

Malware has also exploited STUN for reconnaissance. The Dyreza banking trojan used STUN to discover infected hosts' public IP addresses, helping attackers understand the network topology they had compromised.¹⁶

For security-sensitive applications, STUN can run over TLS on port 5349. The protocol also includes message integrity mechanisms using HMAC-SHA1 and authentication via username/password credentials.

Port 3478 Today

Port 3478 is the default for STUN servers specified in SRV records, for both UDP and TCP.¹⁷ It carries the traffic that makes the modern real-time web possible.

When you open Zoom, Teams, or Meet, your client contacts STUN servers to discover its public address. When a WebRTC application in your browser establishes a peer connection, STUN queries flow through port 3478. An estimated 70-80% of WebRTC connections succeed via STUN alone; the remaining 20-30% require TURN relay.¹⁸

Google operates public STUN servers at stun.l.google.com:19302. Many WebRTC applications point to these as defaults. Commercial TURN/STUN providers offer servers distributed globally to minimize latency during the discovery phase.

Related Ports