NAT Traversal Workbench

Trace how devices behind NAT discover candidates, test direct paths, fall back to relays, or use brokered IoT control.

Learner-ready NAT traversal workbench with STUN, TURN, ICE, port mapping, cloud broker, NAT behavior controls, candidate diagnostics, relay cost, security guidance, source links, and local desktop/mobile visual verification.

Foundation networking STUN / TURN / ICE IoT remote access

NAT Traversal Workbench

Watch an IoT device behind a private router create an outbound mapping, learn the public address a peer sees, test direct connectivity, and then decide whether the safe design is direct, relayed, brokered, or blocked.

Diagnosis ICE should try direct candidates first, then keep TURN ready.

Selected route Server-reflexive direct

Extra latency 32 ms

Current phase Gather candidates

NAT mapping A private address such as 192.168.1.50:51000 is rewritten to a public address and port when the device sends outbound traffic.

Inbound default Packets from the internet are normally dropped unless they match an existing mapping or an explicit port mapping rule.

Reflexive address STUN reports the public IP and port that a server observes; it does not guarantee that every peer can use that address.

Relay fallback TURN relays media or packets when a direct path fails, trading reliability for latency and server bandwidth cost.

Scenario set

Traversal controls

Change the network conditions and compare direct, relay, broker, and router-mapping approaches.

Scenario

Technique ICE: try host, STUN, then TURN STUN and UDP hole punching only TURN relay Cloud broker or reverse connection Manual port forwarding UPnP / PCP / NAT-PMP mapping

Network policy Home router, outbound UDP allowed Enterprise firewall, UDP blocked, TCP 443 allowed Carrier-grade NAT, no user port mapping Managed router, explicit mapping allowed

Device-side mapping behavior Endpoint-independent mapping Address-dependent mapping Address-and-port-dependent mapping

Device-side filtering behavior Endpoint-independent filtering Address-dependent filtering Address-and-port-dependent filtering

Peer-side mapping behavior Endpoint-independent mapping Address-dependent mapping Address-and-port-dependent mapping

Peer-side filtering behavior Endpoint-independent filtering Address-dependent filtering Address-and-port-dependent filtering

UDP mapping timeout

45 s mapping, 20 s keepalive target

Media or payload rate

900 kbit/s stream

Guided task flow

Private LAN Internet services Peer network

IoT device 192.168.1.50:51000

NAT A 203.0.113.42:62014

STUN public mapping discovery

TURN relay candidate

Broker outbound IoT control

NAT B 198.51.100.88:41032

Phone or peer 10.20.0.9:52000

Gather candidates The device contacts STUN to learn the public endpoint. ICE treats this as a server-reflexive candidate, then proves whether the peer can actually reach it.

Candidate set

ICE ranks candidates by preference, but only a successful connectivity check should be used.

NAT mapping table

Outbound traffic creates the table entries that inbound packets must match.

Diagnosis

Direct server-reflexive media is available in this home-router scenario, with TURN kept as a fallback.

Event log

Each row links the packet flow to the decision the application should make.

STUN Discovers a server-reflexive address. It is cheap and fast, but it is not a relay and does not bypass every NAT.

TURN Allocates a relay address. It works when direct checks fail, but every packet consumes relay capacity.

ICE Gathers host, server-reflexive, and relay candidates, runs checks, and nominates a working pair.

IoT default For commands and telemetry, prefer outbound TLS to a broker or cloud service instead of exposing device ports.

Technical notes and primary sources

NAT type language The old cone/symmetric labels are convenient shorthand. The more precise model separates mapping behavior from filtering behavior.

Why STUN can mislead With address-and-port-dependent mapping, the public endpoint observed by a STUN server may not be the endpoint used for a peer.

Security boundary Port forwarding creates a public attack surface. Use VPN, identity-aware tunnels, brokered commands, and TLS rather than exposing embedded web consoles.

RFC 8445: Interactive Connectivity Establishment (ICE) RFC 8489: Session Traversal Utilities for NAT (STUN) RFC 8656: Traversal Using Relays around NAT (TURN) RFC 4787: NAT behavioral requirements for UDP RFC 5128: State of peer-to-peer communication across NATs RFC 6887: Port Control Protocol (PCP)

Practice prompts

Smart camera Set the technique to ICE, then switch device-side mapping to address-and-port-dependent. Explain why TURN becomes the practical fallback.

Enterprise sensor Select the enterprise firewall policy. Compare STUN-only, TURN relay, and cloud broker outcomes for a battery-powered device.

Remote admin Try port forwarding with carrier-grade NAT, then with managed router access. Decide what security controls are still needed.