STUN, ICE & TURN
STUN (Session Traversal Utilities for NAT), ICE (Interactive Connectivity Establishment) and TURN (Traversal Using Relays around NAT) are the protocols that let two devices on the internet find a way to talk directly to each other, even when both sit behind NAT (Network Address Translation) routers or firewalls. They are the foundation of almost all real-time communication on the modern internet: video calls, voice calls, screen sharing and remote-control tools all rely on them to establish a connection.
Because these protocols are specifically designed to punch through NAT and firewalls, they are worth understanding for anyone monitoring a network. Most of the time they represent normal activity (a video call, a conferencing app). But the same mechanics that make a legitimate video call work can also be used to establish peer-to-peer channels that bypass traditional network controls, so it is useful to be able to see what is happening.
Nzyme observes this activity passively and presents it in two separate views, described further below:
- NAT Discoveries: a device asking a public server "what does my public address look like?"
- STUN Connections: two devices negotiating a direct path to each other.
A short primer for analysts
You do not need to be a NAT-traversal expert to make sense of the data, but a little background helps. Feel free to skip this section and refer back to it.
The problem these protocols solve
A device on a private network (for example 192.168.0.50) does not know what its traffic looks like from the outside.
Its router rewrites the address, so the public internet sees something completely different. For two devices behind
two different routers to talk directly (without relaying everything through a central server) each one first has to
discover its own public-facing address, and then the two have to agree on a path that actually works through both
routers.
STUN: discovering your public address
The first step is a device sending a small STUN Binding Request to a public STUN server and getting back a Binding Response that says, in effect, "I received your request from this public address and port." This is how a device learns its own public-facing address.
In Nzyme, this shows up as a NAT Discovery. It is a normal, common, low-risk event — practically every device that uses a modern communication app does this. Seeing discoveries is expected. What can be more interesting is which devices are doing it, how often, and to which servers.
ICE: negotiating a direct path
Once each side has gathered its candidate addresses, the two devices need to agree on a path. First they exchange their lists of candidate addresses with each other, but this exchange happens through the application's own signaling channel (for example, a web service the app talks to over HTTPS), not over the direct path between the two devices. This signaling is out-of-band and encrypted, so Nzyme does not observe the candidate exchange itself.
What Nzyme does observe is the next step: the two devices probing each candidate path to find one that works. This probing uses STUN messages flowing directly between the two peers (rather than to a public STUN server), and it is visible on the network. This is ICE (Interactive Connectivity Establishment).
In Nzyme, this probing shows up as a STUN Connection. Because the two peers probe each other, ICE has no "client" or "server" in the traditional sense and both are equal peers.
TURN: relaying when a direct path is impossible
Sometimes NAT or firewall rules make a direct path impossible. In that case the peers fall back to a relay server (a TURN server) that sits in the middle and forwards traffic for them. TURN is more expensive and slower than a direct connection, so it is used only when necessary, but it is worth noticing, because a relay hides the real remote peer behind the relay's address.
In Nzyme, TURN activity is folded into the STUN Connections view and flagged with a TURN indicator.
STUN Discoveries in Nzyme
A STUN Discovery is a device using a STUN server to learn its own public address. You can find all recorded discoveries on the STUN Discoveries page under NAT in the sidebar of your Nzyme web interface.
Discovery status
Each discovery is assigned one of three statuses, reflecting the most significant thing observed over its lifetime:
| Status | Meaning |
|---|---|
COMPLETE |
The device sent a request and received a successful response. The public address was learned. |
ERROR |
The server returned an error response. |
INCOMPLETE |
A request was observed but no matching response was seen (the exchange was not observed to complete). |
An INCOMPLETE status does not necessarily mean something went wrong. It often just means Nzyme did not observe the
full exchange (for example, the response took a path the tap could not see).
What an analyst can look for
- Baseline: discoveries are normal. Establish what is typical for your environment.
- Unusual sources: a device that has no obvious reason to use real-time communication performing many discoveries may be worth a look.
- Top clients and servers: the discovery view includes histograms of the most active internal devices and the most contacted STUN servers, which help you spot outliers quickly.
STUN Connections in Nzyme
A STUN Connection is a negotiation between two peers attempting to establish a direct (or relayed) path to each other, an ICE negotiation, and/or TURN relay activity. You can find all recorded connections on the STUN Connections page under NAT in the sidebar.
A single connection is identified by its negotiation key — a stable identifier derived from the ICE credentials (ufrags) exchanged during the negotiation. All the individual network flows that belong to the same negotiation are grouped together under this key and presented as one connection.
Successful vs. failed connections
A connection is marked successful when Nzyme observes evidence that a working path was actually established:
- For ICE, both directions of the connectivity check were seen (the peers confirmed a path to each other).
- For TURN, a relay allocation was established.
A connection that was attempted but never observed to complete is shown as not successful. This is common and benign: a call that failed to connect, a negotiation that timed out, or simply a path the tap could not fully observe.
A note on source and destination
WebRTC and ICE are peer-to-peer protocols. Unlike a traditional client/server connection, there is no inherent "source" and "destination", both ends are equal peers, and which one initiated the connection is generally not observable on the wire.
Nzyme therefore orients each connection using the best signal available, in order of preference:
- Which peer sent the most data. For most real-time media (a camera, a remote-control tool, a screen share) one side sends far more than the other, and that heavier sender is shown as the source. This is the most meaningful orientation: it answers "who is sending the stream?"
- Which peer is internal. When one endpoint is on your network and the other is external, the internal device is shown as the source.
- A stable fallback when neither of the above applies (for example, two internal devices exchanging a balanced amount of data).
"Missing" endpoints
Occasionally a connection shows a source or destination as not observed. This happens when a negotiation never succeeded and Nzyme could not associate it with an observed network flow to resolve the endpoints. The connection itself is still recorded (you can see its negotiation details and individual flows), but the summarized endpoint could not be determined. This is expected for some failed negotiations, particularly relayed (TURN) ones involving external peers.
Mapped, peer and relayed addresses
These three address types come directly from the STUN/TURN messages and describe the connection from different angles:
| Address type | Meaning |
|---|---|
| Mapped | A public-facing address a peer learned about itself (the "hole" punched through its NAT). |
| Peer | An address of the other peer, as seen through a TURN relay. |
| Relayed | An address allocated on a TURN relay server that traffic is forwarded through. |
The presence of relayed addresses is a strong indicator that the connection is using a TURN relay rather than a direct path.
What an analyst can look for
- Successful direct connections between internal and external devices: normal for video calls, but worth understanding in a sensitive environment.
- TURN (relayed) connections: the real remote peer is hidden behind the relay. More interesting than a direct connection when investigating where traffic is really going.
- High-byte connections: the connections moving the most data are usually media streams. The STUN Connections view can be sorted by bytes exchanged.
- Connections carrying media: see the WebRTC page, which builds on this data to identify actual audio, video and data-channel activity.
Relationship to WebRTC
STUN, ICE and TURN establish the connection. They do not tell you what flows through it. When a STUN connection is also observed carrying media (audio/video) or a data channel, Nzyme surfaces that as a WebRTC session. If you are trying to answer "is this a video call, and what is it carrying?", start with the WebRTC page.
Configuration
STUN, ICE and TURN detection is part of Nzyme's UDP and TCP analysis and requires no separate configuration beyond having Ethernet monitoring enabled on the relevant interface. See the Ethernet overview for interface configuration.
Additionally, you can tune pipeline performance, but this is rarely required for STUN: