How a VPN Changes (or Breaks) WebRTC File Transfers
What VPNs do to ICE candidates, why some corporate VPNs force every byte through a relay, and how to diagnose it.
VPNs and WebRTC have a complicated history. A VPN changes what network you appear to be on — which is the entire thing WebRTC connection setup depends on. Depending on the VPN, a file transfer gets slower, gets relayed, or fails outright. Here is the mechanics of why.
What a VPN does to your candidates
During setup, each browser gathers the addresses it might be reachable at (ICE candidates). With a VPN active, your public-facing address becomes the VPN exit server's, often in another city or country. Direct connectivity now depends on the VPN provider's NAT behaviour — and most consumer VPN exits behave like strict, symmetric NATs shared by thousands of users. Result: hole punching frequently fails, and transfers fall back to an encrypted relay (what that means).
The historical “WebRTC leak” — and its side effects
Years ago, WebRTC could reveal a user's local and real public addresses to websites, which privacy tools called the “WebRTC leak”. Browsers fixed the worst of it (local addresses are hidden behind per-session mDNS names now), but the episode left a legacy: many VPN apps and privacy extensions still ship a “disable WebRTC” or “WebRTC leak protection” switch. With that switch on, connection setup is crippled or WebRTC is off entirely — the transfer never starts, with no obvious error pointing at the VPN.
Typical outcomes, by setup
| Setup | Likely outcome |
|---|---|
| One side on a consumer VPN | Works, often via relay; slower (traffic detours through the VPN exit) |
| Both sides on VPNs | Almost always relay; latency of both detours adds up |
| VPN with “WebRTC block” enabled | Connection fails at negotiation — disable the block or exempt the site |
| Corporate VPN with strict egress rules | Depends on policy; TURN over TLS/443 is the usual survivor (background) |
| Both devices on the same LAN, VPN on one | Counterintuitively often relay: the VPN side no longer looks local |
Diagnosing it in two minutes
- Check the connection badge: relay mode with both devices side by side is a hint that something (often a VPN) is masking locality.
- Pause the VPN, retry, compare. If the transfer jumps from relay to LAN-direct, you have your answer.
- If pausing is not acceptable, check the VPN app for WebRTC-related toggles, and prefer split-tunneling that exempts the transfer site.
Privacy note
Turning a VPN off for a transfer trades one property for another: you regain direct connectivity, the peer's network sees your real IP. In relay mode with the VPN on, the peer sees the relay, the relay sees the VPN exit. Which arrangement is “more private” depends on whom you are shielding from — there is no universal answer, only trade-offs worth knowing.