Einführung
Level's remote features (remote control, terminal, services, processes, etc) use a WebRTC-based connection between your browser and the target device. When that connection can't go direct, it falls back to relay servers. If remote sessions are slow, failing to connect, or you're seeing "connecting..." indefinitely, this guide helps you figure out where the breakdown is.
How Level Establishes Remote Connections
Level tries to connect in this order, stopping as soon as one succeeds:
Direct P2P — your browser connects directly to the device. Lowest latency, no intermediary.
STUN — uses
global.stun.twilio.comto punch through NAT and discover a direct path.TURN over UDP (port 3478) — traffic relays through
global.turn.twilio.com.TURN over TCP (port 3478) — same relay, TCP instead of UDP for stricter firewalls.
TURN over TLS (port 5349) — last resort; encrypted relay for the most restrictive environments.
All connections are initiated outbound from both the browser and the agent. You shouldn't need inbound firewall rules.
ℹ️ NOTE: Relay connections (TURN) add latency compared to P2P. If you're consistently on relay, the session will work but may feel slower. The goal of this guide is to get you to P2P or at least confirm that relay is functioning correctly.
Test Your Connection
Twilio Network Test
Run this from the browser on the machine you use to access Level (the tech side, not the endpoint): Twilio Network Test
This tests whether your browser can reach the STUN and TURN servers Level uses. If TURN tests fail here, remote sessions will fail or time out from your location.
Trickle ICE Test
The Trickle ICE tool tests whether valid ICE candidates can be gathered for a WebRTC connection: Trickle ICE
Use these values:
STUN server:
stun:global.stun.twilio.com:3478TURN server:
turn:global.turn.twilio.com:3478
If no srflx candidates appear, STUN is blocked. If no relay candidates appear, TURN is blocked. Either result means firewall changes are needed on the tech side.
Common Causes and Fixes
Remote sessions fail to connect entirely:
The tech-side browser can't reach TURN servers. Run the Twilio Network Test from your browser to confirm. If it fails, your corporate network or VPN may be blocking UDP 3478 or TCP 3478 outbound.
The agent-side network is blocking the same. Check the network requirements in Offline Troubleshooting and confirm the device can reach
global.turn.twilio.comoutbound on 3478.
Remote sessions connect but are slow or drop frequently:
The connection is on relay (TURN) rather than P2P. This is expected on heavily NATted or firewalled networks. Relay adds round-trip latency — if both sides have internet access, TURN relay should still be usable.
Check for packet loss between the agent and
global.turn.twilio.comusing a traceroute or ping.
Sessions work from some networks but not others:
The issue is specific to that network's firewall configuration. Use Trickle ICE from that network to confirm which candidates are blocked.
Required Network Access
For remote connections to work, both your browser and the target device need outbound access to:
Endpoint | Port | Protocol | Purpose |
| 3478 | UDP | STUN — NAT traversal |
| 3478 | TCP & UDP | TURN relay |
| 5349 | TCP | TURN TLS (last resort) |
💡 TIP: Start with UDP 3478 outbound. Most networks that need TURN at all can use it on UDP 3478 without opening anything else. Only move to TCP 3478 or 5349 if UDP is blocked.
Checking Whether a Session Is P2P or Relay
Level shows the connection type directly in the UI — no packet capture needed.
Remote Control — look for the connection badge in the top-left of the session toolbar. It shows P2P or Relay.
Background Management (Terminal, File Explorer, Processes, Services) — look for the badge in the top-right of the session toolbar. It shows Connected: P2P or Connected: Relay.
Hover over the badge to see which side is on relay — it'll indicate whether the issue is on the tech side (your browser), the device side (the agent), or both. That tells you exactly where to focus the network investigation.
Häufig gestellte Fragen
Remote control connects but feels laggy. Is that a relay issue? It could be, but there are a lot of factors that affect session performance. Start by checking the connection badge — if it shows P2P, the connection type isn't the issue and something else is causing the lag. If it shows Relay, hover over the badge to see which side is on relay, then work through the network requirements for that side.
The Twilio Network Test passes but remote sessions still fail. The test runs from your browser. The device side also needs outbound access to the same TURN endpoints. Run
--checkon the device (see Troubleshooting Agent Issues) and look for TURN-related failures. If the device is on a more restrictive network than your browser, it may not be able to reachglobal.turn.twilio.com.Do I need to open inbound firewall ports for Level remote access? No. All connections originate outbound from both the browser and the agent. You don't need inbound rules.
The badge says Relay. How do I get P2P working? Hover over the badge first — it'll tell you which side is on relay. If it's the device side, check that the device can reach
global.stun.twilio.comandglobal.turn.twilio.comoutbound on UDP 3478. If it's the tech side (your browser), run the Twilio Network Test from that network. If both sides show relay, check both. In heavily restricted environments (strict egress filtering, carrier-grade NAT), relay may simply be the permanent mode — sessions will still work, just with added latency.