Why Some Networks Refuse Direct WebRTC Connections

By ShareDrop.org Engineering · Published Jul 24, 2026 · Updated Sep 21, 2026

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.

6. Local-network permission and hidden addresses

Two newer causes live on the device rather than in the network. Modern browsers do not put your local address into the connection setup; they use a random name that the other device resolves with multicast DNS, which only works on the same network, and only if that network passes multicast. On macOS and iOS, the operating system also asks each app for permission to use the local network the first time; a browser or app that was denied gathers no usable local candidate at all. Both produce the same symptom: two devices side by side connect Internet direct through the router's public side, or via a relay, instead of LAN direct. The transfer works; it is just not taking the short path.

How often each one shows up

Ranked roughly from most to least common, with the quickest way to recognise each:

Diagnosing it in two minutes

1. Read the badge. LAN direct means none of this applies. Internet direct on the same Wi-Fi points at cause 6. Encrypted relay points at everything else; the transfer still works.
2. Pause any VPN on both devices and retry. If the badge changes, that was it.
3. Put one device on a phone hotspot and retry. If it now connects directly, the original network was isolating, blocking UDP or behind CGNAT. If it still relays, the other device's network is the constraint.
4. If nothing connects at all, not even via relay, the network is blocking unknown destinations. A hotspot for the whole transfer is the only fix short of talking to whoever runs the network.

The cause that is really a cure: IPv6

On IPv6 there is no address translation, so there is no port to guess and no mapping to expire; the router's firewall still drops unsolicited packets, but the connectivity check itself opens it. When both devices have working IPv6 (common on mobile carriers, less so on fixed lines), the direct IPv6 pair usually wins even where the IPv4 pairs would have failed. Two phones on IPv6-capable carriers can connect directly despite both being behind CGNAT. A peer without IPv6 forces everything back to the IPv4 rules above (the details).

Things that do not cause it

• File size. Connection setup happens before any file data; a 10 KB file and a 10 GB file negotiate identically.
• Which browser. Chrome, Firefox, Safari and Edge all run the same ICE procedure; differences show up in saving files, not in connecting.
• The HTTPS page. The page loading over HTTPS is unrelated to whether the peer-to-peer path can be made; one is browser-to-server, the other browser-to-browser.
• Ad blockers, usually. Content blockers do not touch WebRTC. Some privacy extensions do, with a “prevent WebRTC leaks” option that disables it — the same failure as a VPN's WebRTC block.
• Distance. Two devices on opposite sides of the world connect directly as readily as two in one city, if their networks allow it; distance adds latency, not failure.

What to ask a network administrator for

If an office network blocks transfers and you have someone to ask, the request is small and specific: allow outbound UDP to port 3478 (STUN and TURN), or at minimum outbound TCP to 3478 and 443 to the relay's address. No inbound rule is needed (everything is initiated from inside), and no port forwarding. Client isolation on a guest network is usually there on purpose and will not be lifted; a hotspot is the honest answer there.

How long a failure takes to show

Because a blocked path looks identical to a slow one until a timer runs out, a transfer on a hostile network spends longer “connecting” than a working one spends transferring a small file. Direct candidate pairs are each retried for several seconds before being abandoned; the relay pair is tried in parallel and usually rescues the connection within two or three seconds of the code being entered. A failure message after thirty seconds or so means every path, relay included, was refused. Retrying immediately on the same network rarely helps (nothing has changed), but retrying after switching one device to a hotspot changes everything, because it gives ICE a new set of candidates to try.

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.

Standards behind this article

• RFC 8445: Interactive Connectivity Establishment (ICE): candidate gathering, pairing, and the order in which paths are tried.
• RFC 4787: NAT Behavioral Requirements for Unicast UDP, the source of the mapping and filtering terms used for causes 1 and 2.
• RFC 6888: Common Requirements for Carrier-Grade NATs, what a CGNAT is expected to do and why it sits in front of so many mobile users.
• RFC 8656: Traversal Using Relays around NAT (TURN), including the TCP and TLS transports that survive UDP blocking.
• RFC 8421: Guidelines for Multihomed and IPv4/IPv6 Dual-Stack ICE, how IPv6 pairs are interleaved with IPv4 ones.