VPN vs TURN Relay: Which One Actually Carries a WebRTC Call?
A tunnel changes the path ICE observes; it never allocates a relay or supplies signaling. Compare what a VPN exit and a TURN server each provide.
Page loads over the VPN, call never connects: two different failures wearing the same address bar. The tunnel changed the path the browser uses; it did not become a signaling service, a STUN server or a relay, and it does not decide which candidate pair ICE will pick. Separating the job each component performs is what turns a vague "WebRTC is blocked" into a specific fault.
Four jobs, only one of which the tunnel touches
The application exchanges session information through some signaling arrangement, and that is the first job. ICE gathers candidate addresses and tests pairs until one works, which is the second. STUN lets a peer learn how its traffic appears from outside, and TURN allocates a relay for cases where no direct path exists. Those four roles are distinct, and a VPN affects the addresses and filtering they encounter rather than supplying any of them.
That is why a working login tells you nothing about the media path. Signaling usually rides the same HTTPS the page already uses, on port 443, while the media may travel over UDP to a completely different destination.
Private addressing makes the confusion worse. A tunnel address is useful to a peer only when that peer has an intended path back to it; being private is not evidence of mutual reachability, and browsers do not treat it as such when they discard candidates that cannot be checked. A candidate that looks local to you may be untestable from the other side. That gap is worth ruling out before you conclude the tunnel is dropping media.
Compare a VPN exit with a TURN relay
Both forward packets, which is why they get conflated, and the comparison table above is worth reading column by column rather than as a list of features. A relay allocation is a per-session object created by an authenticated request; a tunnel is a route. One has credentials that expire, the other has a peer address that either is reachable or is not.
| Component | What it contributes | What it needs to work | What it cannot do |
|---|---|---|---|
| VPN exit | Changes the observed mapping and the route packets take | A working tunnel and a policy that permits the media transport | Allocate a relay or supply signaling |
| STUN server | Reports the mapped address a peer appears to use | Reachability from the client, on its configured transport | Carry media when a direct path fails |
| TURN server | Relays media through an authenticated allocation | Valid credentials, an allowed transport and sufficient capacity | Fix a missing ICE policy or an unauthorized client |
| Signaling channel | Carries offers, answers and candidate lists | Both peers reaching the same application endpoint | Establish connectivity by itself |
Port numbers make the difference concrete. TURN listens on 3478 for UDP and TCP and on 5349 for TLS by default, and a network that permits 443 while dropping those ports will fail relayed calls while browsing continues normally. Changing the VPN's port does not configure any of that, because the ports that matter belong to the relay service, not to the tunnel.
Read the diagnostics, then test the call
Browsers expose the information you need without a packet capture. Open the WebRTC diagnostics page for your browser, make the call, and read the selected candidate pair rather than the gathered list: which local and remote candidate types were chosen, over which transport and address family, and whether the path is direct or relayed.
Two readings are worth knowing in advance. If the selected pair is host-to-host on private addresses, the media is staying on a path you can reason about; if it is relay-to-relay, the call is spending relay capacity and depends on that service's availability. A failure that stops at "checking" with no selected pair means candidates were gathered but none passed the connectivity checks.
Then compare the same two endpoints on the same call while changing only one approved condition, and accept the result on two-way media or data rather than on a connected indicator. Candidate gathering succeeds in plenty of cases that never carry a single frame of audio. Repeat the call on the other side of the change and keep both diagnostic captures, because comparing two runs is more informative than reading either one alone. Same endpoints, same codec, one variable altered.
An application that deliberately sets its ICE transport policy to relay is asking for relay candidates only. That setting does not create a relay and does not repair missing credentials; it makes the requirement explicit, which is useful when someone blames the VPN for a policy the site chose.
Keep the privacy claim as narrow as the evidence
Candidate exposure depends on browser and application policy, not on tunnel status alone, and the W3C peer-connection specification treats IP handling as its own concern. A connected VPN is therefore a poor basis for promising that a call reveals only one chosen address. Two peers behind the same tunnel can even select a path that never leaves the host, which is a privacy improvement and a connectivity constraint at the same moment.
What you can state precisely is narrower and more useful: which candidate pair was selected, which transport carried it, and whether that path stayed inside the tunnel. Record those three facts for a working call and for a failing one, and the difference usually names the component to fix.
Once connectivity works, separate performance from reachability. Loss, delay, queueing and MTU all sit downstream of a correct candidate pair, and treating a choppy call as a connectivity failure sends you back to the candidate list for no reason.