WebRTC and a VPN, in Plain English

Web Real-Time Communication is a set of APIs in Chrome, Firefox, Edge, Safari, and the rest. Audio. Video. Data channels. The point was peer-to-peer without Flash. MDN will give you RTCPeerConnection if you want the object name. You do not need the object name to use a VPN. You need to know the browser can open a path that is not your ordinary HTTPS tab.

Ordinary HTTPS: the OS routes to the VPN adapter, the packet exits at a VPN IP, the site sees that IP. WebRTC: the page asks the browser to gather candidates so a call can start. Gathering looks at interfaces. Interfaces include the Ethernet or Wi-Fi NIC that still has a LAN address and, often, a NAT mapping to your home public IP. The VPN adapter is another interface. ICE tries more than one.

A competitor farm will call this a massive vulnerability and then sell a browser extension. Fine as marketing. As physics, it is a call stack doing call-stack work on a machine that also has a tunnel.

If you never visit a page that runs the script, you may never see it. Trackers and test pages do run the script. That is why the leak has a reputation. It is not because WireGuard forgot how to encrypt TCP.

NAT hides many home machines behind one public IP. A call still needs a way to say hello from outside. STUN is a small server that looks at the packet you sent and replies: this is the public mapping I saw. The browser uses that reply as a candidate. Session Traversal Utilities for NAT is the long name.

The important part: STUN is not the VPN. It is not DNS. It is not TLS. It is a mirror for an address. If the packet to the STUN server left via the physical NIC, the mirror shows the home mapping. If the packet left via the VPN adapter, the mirror shows a VPN mapping. ICE may try both. A test page prints whatever came back.

People hear STUN and think stun as in attack. It is a protocol name. The attack, if you want that word, is a page reading the candidate list you did not know was public to JavaScript. The protocol is doing what it was asked.

TURN is the fallback when STUN is not enough: relay the media through a server. Relays cost money and add latency, so ICE prefers a direct path when it can. Direct is how home IPs show up. Direct is also how a call stays cheap.

Interactive Connectivity Establishment is the boring name for: try a list of addresses until two peers can talk. Each attempt is a candidate. Three flavors matter for this essay.

Host: an address on an interface you actually have. Often 192.168.x.x on Wi-Fi. Sometimes a link-local. Sometimes the VPN adapter's own internal address. Host candidates tell a page you have a LAN. They do not always tell the page your ISP IP. They still annoy people who wanted zero local topology in JavaScript.

Server reflexive, srflx: what STUN saw. This is the one that dumps a home public IPv4 when ICE used the NIC that NAT's to the ISP. This is the screenshot in every farm article.

Relay: TURN. If the call had to bounce, you see a relay address. That can be better for hiding the home IP and worse for quality. ICE picks based on connectivity, not based on your privacy blog.

IPv6 adds more candidates. If the NIC has a global v6, ICE may volunteer that too. The IPv6 Leak: Why It Happens and How to Test article is the other family leaving the tunnel for ordinary traffic. WebRTC can volunteer v6 even when you thought you only cared about v4 HTTPS. Sibling, not a clone.

A consumer VPN adds a virtual adapter and a default route. Packets that follow the default route go into WireGuard or OpenVPN and come out elsewhere. The physical NIC does not vanish. It still has a DHCP lease. It still speaks to the router. It still has a NAT mapping through the home gateway. WebRTC is allowed to ask that NIC for a candidate because a call to a person on the same LAN should not hairpin through a VPN in another country if a local path exists.

That last sentence is the design. Same-LAN calls want the LAN. Privacy-minded VPN users want every public mapping to be the VPN. Those goals fight. The browser does not know which goal you had when you opened a news site that loaded a tracker.

Split tunneling makes this louder. If you excluded the browser, of course ICE sees the NIC. If you did not exclude the browser, ICE can still see the NIC because gathering is not the same code path as fetch(). Different sockets. Different APIs.

Five devices means five browsers with five ICE moods. Fixing Chrome on the laptop does not fix Safari on the phone. The seat count is not a WebRTC setting. It is why you test the surface you actually use.

Broken VPN, in the useful sense, is: the toggle is green and your ordinary web IP is still home. Or DNS still goes to the ISP. Or IPv6 walks around the tunnel. Those are path failures. WebRTC showing a NIC candidate while icanhazip-style HTTPS shows the VPN egress is a browser volunteer, not a dead WireGuard handshake.

If both HTTPS and ICE show home, then you do have a tunnel problem. Fix the tunnel first. Do not start in about:config. The Leak Test After You Connect a VPN order exists because people reverse it. They see a WebRTC number, nuke Firefox, and never notice the adapter never connected.

OpenVPN TCP when UDP is rude is a protocol picker issue. It is not ICE. Do not switch protocols to cure a STUN script. Switch protocols when the handshake itself fails. Look at your own test page. That is the only result that matters for your laptop.

JavaScript on a page can create a peer connection, wait for onicecandidate, and read the SDP or the candidate string. No camera prompt is required for ICE gather in many setups. You did not click Allow microphone. You loaded the page. That is enough for a nosy script.

What it gets: maybe a LAN IP. Maybe a home public IP. Maybe only a VPN IP if blocking worked. Maybe a pile of all three. Correlation is the privacy hit. The site already saw the VPN egress on the HTTPS connection. The script adds the home mapping. Now they can stitch. That stitch is why people who use a VPN to hide an IP from a site should care.

What it does not get: your Klox password. Your invoice. The contents of HTTPS bodies. A STUN candidate is an address, not a session cookie. Do not inflate it into a full identity theft. Also do not shrug if hiding the IP was the reason you paid.

Logged-in Google plus a leaked home IP is a stronger stitch than either alone. The What a No-Logs VPN Does Not Mean essay is identity at the account layer. This is identity at the ICE layer. Both can be true on the same afternoon.

The features page lists WebRTC leak blocking, automatic on all servers, next to all DNS through the VPN tunnel and IPv6 leak protection. That is a client-side product sentence. It means the app is supposed to stop the volunteer, not that every browser on earth became polite without the app.

I will not diagram unpublished internals. If I invent a method, it will rot and someone will file a ticket against the diagram. The honest version: install the client, connect, then verify ICE on the browser you use. If the home public IP is gone from the candidate list, the feature is doing the job for that surface. If it is still there, go to the WebRTC Leak: Can It Expose Your IP with a VPN? post and clamp the browser. Features are not a substitute for a measurement.

Blocking can annoy a real call. If Meet fails after you connect, you may need WebRTC on for that tab and a leak test after. Privacy and a video standup fight. Pick per hour. The feature is on the list. The test is still yours.

Names go to a resolver. Klox's default is all DNS through the VPN tunnel. The ISP should see a blob, not a shopping list of names. That hop is What DNS Does on a VPN (Plain English). It does not stop ICE. A STUN script does not ask DNS for your home IP. It asks the NIC and a STUN server.

People collapse leak into one word. Then they change DNS settings to cure WebRTC. Then they break name resolution and still print a srflx candidate. Stop collapsing. DNS test for names. WebRTC test for candidates. IPv6 test for the other family. IP test for ordinary HTTPS.

Split-out apps may keep system DNS and also keep a talkative browser. Two failures for the price of one exclude. If you split, you opted into the NIC. Own that.

RFC 8446 still encrypts the web body. Encrypted body plus leaked ICE is a common state. The padlock never promised to cover RTCPeerConnection.

Connect. Open a WebRTC leak test. See whether the home public IP is in the list. If it is, clamp the browser or confirm the client blocking, then test again. Firefox has preferences. Chromium often wants an extension or a policy. Safari has its own mood. That procedure, including about:config names, lives in WebRTC Leak: Can It Expose Your IP with a VPN?. I am not pasting it.

The Leak Test After You Connect a VPN is the ten-minute order: baseline IP off, connect, IP on, DNS, WebRTC, IPv6. Use that when you want a ritual. Use this post when you want to know why the ritual has a WebRTC row.

Farms will give you a six-step with browserleaks and a country pick. Nord's page is a specimen of that genre. Country pick is not required to understand STUN. It is required if you are testing streaming geo, which is a different disappointment. Streaming limits are another article.

If you came here for the Firefox tutorial, you are in the wrong file on purpose. I will not clone it so this post can rank for the same query. Go to the how-to.

A standup, a doctor visit, a class, a family call: that is WebRTC earning its keep. The tunnel can still encrypt the rest of the laptop. The call may still want a working ICE path. If blocking breaks the call, you learned the feature is doing something. Decide whether the call or the hidden IP wins for the next hour.

A news site with a tracker is not a standup. There the volunteer is not earning its keep. Blocking is the default I want on a machine I use for both. When the call fails, I loosen, then I tighten. I do not leave it loose because last Tuesday had a Zoom.

Klox will not be in the room for that choice. The client lists leak blocking. The how-to lists browser clamps. You still pick. Five devices means someone else in the family may pick wrong. Tell them the English, not a screenshot dump, unless they asked for the how-to. You know the VPN can be honest while the browser is talkative.