Culvert VPNWebRTC leaks: what they are, and whether Android apps are affected
A WebRTC leak is a browser handing your real IP to a web page while a VPN is on; mainly a desktop problem, and Android apps with no browser are unaffected.
A WebRTC leak is when a web page reads your real IP address out of your browser while a VPN is connected. It happens because the browser's real-time communication code, the part that makes browser-based video calls work, asks an outside server what your public address is and then hands the answer to the page's JavaScript. It is mostly a desktop-browser problem. On Android it can only affect a browser or an app that embeds one; a native app that never loads web content has nothing to leak through, and a VPN that routes all of the phone's traffic sends the browser's address-discovery requests through the tunnel as well.
What WebRTC is
WebRTC is the set of browser features that let two browsers send audio, video and data directly to each other without a server in the middle. Every browser-based video call, and a good number of file-transfer and screen-sharing pages, run on it.
For two devices to talk directly, each has to learn what addresses it can be reached at. The browser gathers a list of candidates: its address on the local network, its public address as seen from the internet, and sometimes a relay. To find the public one it sends a small request to a STUN server, which replies with the address it saw the request come from. All of this happens in JavaScript with no permission prompt, because gathering candidates is not the same as starting a call.
How the leak happens
The leak is simply that a web page can start candidate gathering and read the list, without ever placing a call. If the STUN request goes out over your normal network rather than through the VPN, the STUN server reports your real public address and the page now has it, even though every ordinary request from that page is going through the tunnel and shows the exit IP.
On a desktop, this is a real gap. Some VPN clients only capture the traffic they were asked to, or leave UDP alone, and the STUN request slips past. The local candidates are a smaller matter: a 192.168 or 10.x address is your phone's address on the Wi-Fi, which is the same on millions of other networks and identifies nothing on its own, and current browsers hide those behind random names anyway.
Is Android affected?
It depends entirely on where the web content is running.
| What you are using | Can it leak this way? |
|---|---|
| A native app with no web content: messaging, banking, mail, maps | No. There is no browser engine and no JavaScript |
| A browser app | Same code as on a desktop, so in principle yes; whether it does depends on the VPN |
| An app that shows web pages inside itself (a WebView) | In principle yes, though such pages rarely run WebRTC |
The second half of the answer is how Android VPNs work. A VPN app on Android takes a system-wide tunnel interface, and every packet from every app, over TCP and UDP alike, is routed into it unless the app was deliberately excluded. The browser's STUN request is a UDP packet like any other, so it goes through the tunnel, and the STUN server reports the exit IP, which is what you wanted the page to see. The leak needs traffic that goes around the tunnel, and on Android that only happens if the browser is on the split-tunnel exclude list or the tunnel is not carrying traffic at all.
That is why the WebRTC problem is mainly heard about on desktops: the VPN designs that let a STUN packet escape are desktop designs.
Testing it on Android
- Connect the VPN and confirm the exit IP has changed, using the steps in how to check your VPN is working.
- Open a browser that is not excluded from the VPN.
- Open a WebRTC test page. These pages start candidate gathering and list every address the browser found.
- Ignore any 192.168, 10.x or 172.16 to 172.31 address, and any entry that is a random name ending in
.local. Those are local candidates. - Look at the remaining public addresses. If they match the exit IP, there is no leak. If one matches the address your carrier or ISP gave you, the browser is leaking.
Check IPv6 candidates as carefully as IPv4. A VPN that leaves IPv6 outside the tunnel leaks through STUN for exactly the same reason it leaks through ordinary requests; the IPv6 post covers that.
If the browser does show your real address
On Android, the most likely cause is not WebRTC itself but one of two ordinary leaks: the browser is on the VPN's exclude list, or the tunnel is up without carrying traffic. Check the split tunnelling settings first, then run the general IP leak test. If both are clean and a public address that is not the exit IP still appears, the browser has a setting or extension controlling WebRTC's address gathering; most browsers have one, under privacy or site settings, that limits candidates to the default route only.
Culvert VPN routes every app's traffic, TCP and UDP, through its tunnel unless you exclude the app yourself, so a browser's address-discovery requests travel through it and report the exit IP; it is on Google Play.
Questions people also ask
Does a WebRTC leak affect apps like messaging or banking?
Not unless the app embeds a web page. WebRTC is code inside a browser engine, and a native Android app that never loads web content has nothing to leak through.
The test shows a 192.168 or 10.x address. Is that a leak?
That is your phone's private address on the local Wi-Fi, which is the same on millions of home networks and identifies nothing on the internet. Current browsers replace it with a random name anyway. A leak is the test showing your public address, the one your carrier or ISP gave you.
Can a VPN app stop WebRTC leaks on Android?
A VPN that captures every app's traffic, including UDP, sends the browser's address-discovery requests through the tunnel too, so the page sees the exit IP. What it cannot do is reach inside the browser and change its behaviour.