How a VPN Changes (or Breaks) WebRTC File Transfers
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.
What happens to each candidate type
| Candidate | Without a VPN | With a full-tunnel VPN |
|---|---|---|
| host | Your Wi-Fi address; lets a device on the same network connect directly | The VPN adapter's address (often 10.x), reachable by nobody on your LAN — the local path is gone |
| server-reflexive | Your router's public address, usually punchable | The VPN exit's address, behind the provider's NAT, usually symmetric — rarely punchable |
| relay | Direct path to the relay | Still works, but every packet detours through the VPN exit before reaching the relay |
That first row is the one that surprises people: a VPN on one laptop makes it invisible to the phone on the same desk, because the address it advertises belongs to a network the phone is not on.
Not all VPNs are the same kind of thing
- Consumer privacy VPNs route everything through a shared exit. This is the case described above: symmetric NAT at the exit, an extra round trip to another city, and, in many apps, a switch that disables WebRTC altogether.
- Corporate VPNs route everything through the company's gateway, which typically blocks UDP and enforces the office firewall on a laptop that is physically at home. Expect a relay over TCP, and expect the company's bandwidth caps to apply (why UDP matters).
- Mesh VPNs (Tailscale, ZeroTier, WireGuard between your own devices) are the opposite case. They give each of your devices a private address that the others can reach from anywhere, so a host candidate on the mesh address works across the internet: two of your own laptops in different cities can connect LAN direct over the mesh. If you already run one, leave it on.
Split tunnelling: keeping the VPN on and the transfer direct
Most VPN apps can exempt specific apps or sites from the tunnel. Exempt the browser you are transferring with, or the ShareDrop.org app, and the transfer uses your real network while everything else stays inside the VPN. On Android this is a per-app setting in the VPN app; on iOS it depends on the provider; on desktop most consumer VPNs offer it by app name. Corporate VPNs often forbid it by policy, in which case the relay over TCP is what you get, and it works, slowly.
The leak, precisely
The original 2015 finding was that a web page could ask the browser to gather ICE candidates and read back the local network address and, in some VPN configurations, the real public address, because the STUN request went out over the physical interface rather than through the tunnel. Two things have changed. Browsers now replace local addresses in candidates with random mDNS names, so a page learns nothing about your LAN. And VPN apps with a proper kill switch route STUN through the tunnel like everything else, so the reflexive address is the VPN exit's.
What has not changed, and cannot, is that on a direct connection the peer learns whatever public address the connection uses: that is what a direct connection is. With the VPN on, that address is the VPN exit's; with it off, it is your router's. The ShareDrop.org page itself sees neither, because it only ever watches the negotiation, not the addresses inside it.
Speed under a VPN
The encryption itself costs almost nothing on modern hardware. What costs is the detour: a VPN exit in another country adds its round trip to every packet, and a relay on top of that adds another hop. UDP inside a VPN tunnel also tends to hit packet-size limits and get fragmented, which shows up as lower throughput than the raw link allows. And many consumer VPN plans cap speed outright. A transfer that runs at 3 MB/s with the VPN on and 25 MB/s with it off is not a bug in either product; it is the path (the full diagnostic).
What to do, by what you want
| Goal | Do this |
|---|---|
| Fastest transfer | Pause the VPN, or split-tunnel the transfer app |
| Hide your address from the peer | Keep the VPN on and accept the relay; the peer sees the relay, the relay sees the VPN exit |
| Corporate policy forbids turning it off | Let it relay over TCP; expect it to be slow but complete |
| The transfer never starts at all | Look for a “WebRTC block” or “leak protection” toggle in the VPN or a browser extension and exempt the site |
| Two of your own devices, often | A mesh VPN makes them directly reachable everywhere |
Testing whether your VPN blocks WebRTC
- With the VPN on, start a transfer and open
chrome://webrtc-internalsin Chrome (about:webrtcin Firefox). - Look at the local candidates. Host and relay candidates only, with no server-reflexive one, means STUN is being blocked or answered with the VPN exit — expect a relay. No candidates at all, or no connection object, means WebRTC is disabled by the VPN app or an extension.
- Pause the VPN and repeat. The difference is your answer, and it tells you whether split tunnelling would be enough (candidates appear) or whether the VPN's own WebRTC switch is the problem (they do not).
On phones the equivalent is simpler: the VPN app's per-app settings, where the transfer app can be excluded on Android and, with some providers, on iOS. A VPN installed by an employer usually has no such setting, and the relay is what remains.
Kill switches and reconnects mid-transfer
A VPN that drops and reconnects during a transfer changes the device's apparent address twice in a few seconds. The browser notices, restarts ICE, and (if the new path can be found) the transfer continues, possibly switching between direct and relay. A VPN kill switch cuts all traffic during the gap instead, which looks like a brief disconnection; the transfer waits and resumes from the last verified chunk when the tunnel is back. Neither is fatal. A VPN that flaps every few minutes will make a long transfer slow and lumpy, and is a reason to pause it for the duration.
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.
References
- RFC 8828: WebRTC IP Address Handling Requirements, the rules browsers adopted after the 2015 leak for which addresses a page may learn.
- IETF draft: mDNS ICE candidates: how local addresses are replaced by random
.localnames in connection setup. - RFC 4787: NAT Behavioral Requirements for Unicast UDP, the mapping behaviours that decide whether a VPN exit allows hole punching.
- RFC 8445: Interactive Connectivity Establishment (ICE), the candidate gathering and pairing a VPN interferes with.
