Why Some Networks Refuse Direct WebRTC Connections
NAT types, CGNAT, UDP-blocking firewalls and enterprise proxies: the network conditions that force WebRTC traffic through a relay.
Sometimes two devices connect instantly and directly. Sometimes the very same app, the very same devices, end up on a relay — or fail entirely — just because one of them moved to an office network. The difference is almost always one of the following network conditions.
1. Ordinary NAT (usually fine)
A home router translating private addresses to one public address is the normal case. WebRTC's hole punching (STUN) handles most home routers because they use the same public port for a given internal socket regardless of destination — so an address learned from the STUN server also works for the peer.
2. Symmetric NAT (hole punching dies)
A symmetric NAT allocates a different public port for every destination you contact. The port your peer learned from signaling is not the port your router will use to talk to that peer — probes miss, pairs never validate, and ICE falls back to relay. Symmetric NAT is common on corporate firewalls and some mobile carriers.
3. Carrier-grade NAT (two layers deep)
Many ISPs — mobile networks especially — put customers behind a second, shared NAT layer (CGNAT). Your router's “public” address is itself private. Two CGNAT users can often still connect if at least one side's mapping behaves classically, but the failure rate rises sharply, and CGNAT + symmetric behaviour is a guaranteed relay.
4. UDP blocked (the corporate classic)
WebRTC strongly prefers UDP. Plenty of enterprise, campus and hotel networks allow only TCP ports 80/443. In that world nothing about hole punching matters — no UDP, no direct WebRTC. The escape hatch is TURN over TCP, and ultimately TURN over TLS on port 443, which is indistinguishable from ordinary HTTPS traffic to most middleboxes. Expect noticeably higher latency and somewhat lower throughput than UDP.
5. Interception and lockdown
Networks that man-in-the-middle TLS (some corporate proxies) or block unknown endpoints entirely can defeat even TURN/TLS. At that point the transfer honestly cannot proceed on that network — a tool that claims otherwise is bluffing. A phone hotspot is the standard workaround.
A note on local networks
Counterintuitively, “same network” can also fail: guest Wi-Fi with client isolation blocks devices from seeing each other, and modern browsers hide local addresses behind mDNS names (xxxx.local) for privacy — which some networks and OS permission systems refuse to resolve. In those cases devices standing a meter apart still connect via STUN reflexive addresses or a relay. The app's connection badge (reading it) tells you what actually happened.
What this means practically
- Failure to connect directly is a property of the network pair, not the app or the devices.
- A service without TURN relays simply fails on hostile networks; that is why ShareDrop.org treats relays as mandatory infrastructure.
- If a transfer will not start at all, test on a hotspot first — it isolates whether a restrictive network is the cause. More steps: troubleshooting.