Blocking WebRTC Leaks When Using a VPN

WebRTC (Web Real-Time Communication) is brilliant for low-latency voice/video/file-sharing in browsers — and notorious for IP leakage. Even with a VPN active, WebRTC can expose your real public IP (and sometimes your private RFC1918 address) via ICE candidate gathering and STUN/TURN lookups. This guide explains exactly how WebRTC leaks happen, how to verify them, and multiple layers of hardening: per-browser settings, enterprise policies, OS-level firewalls, VPN-side protections, and practical test/monitoring workflows. It’s fully formatted for WordPress and preserves your existing links.

 

1) WebRTC basics: ICE, STUN, TURN, candidates, and why leaks occur

When a web app initiates WebRTC, the browser gathers ICE candidates — possible network paths to reach peers. Typical candidate types:

• Host: your local/private IP (e.g., 192.168.1.15).
• Server-reflexive (srflx): your public IP discovered by a STUN server (e.g., Google’s stun.l.google.com:19302).
• Relay: a TURN server (relayed through an intermediary when peer-to-peer fails).

If the browser queries STUN outside the VPN interface, the srflx candidate can reveal your real ISP IP to the page, even while the rest of your traffic is tunneled. Also, older/looser settings can expose host candidates (your RFC1918 IP), which sometimes de-anonymizes corporate network topologies. Modern Chromium/Safari obfuscate hosts with mDNS, but srflx can still betray your true public IP unless you prevent non-proxied UDP or force WebRTC to stay within the VPN/proxy path.

---

2) Risk model: what can leak and when

• Public IP leakage: The main risk — srflx candidate shows your ISP egress IP, not the VPN’s exit.
• Local IP exposure: Lower risk for anonymity, but can reveal corporate subnets (host candidates). mDNS mitigates this in many browsers.
• Metadata: STUN connectivity checks and TURN allocations to third-party infrastructure.

Leak likelihood is higher when sites run WebRTC JS (for conferencing, P2P transfer, or even fingerprinting) and your browser allows non-proxied UDP to STUN servers while on a VPN.

---

3) Leak testing: verify before/after hardening

Test with at least two services and note your observed IP(s):

• BrowserLeaks WebRTC
• ipleak.net

Steps:

1. Connect VPN → run tests → record Public IP/WebRTC IP.
2. Disconnect VPN → run tests again (to confirm real ISP IP).
3. Apply hardening → reconnect VPN → rerun tests to validate fix.

Advanced: In Chromium, open chrome://webrtc-internals and watch ICE candidates (look for srflx vs relay). In Firefox, visit about:webrtc.

---

4) Hardening Chrome/Chromium/Brave/Edge (desktop)

Chromium browsers continually evolve; the most reliable strategies today:

4.1 Prefer VPNs or extensions that disable non-proxied UDP

• Use a VPN client that offers a “block non-VPN traffic” / “disable non-proxied UDP” option. This forces WebRTC to use the VPN path (or fail). See the VPN-side section.
• Use a privacy extension that disables/weaken WebRTC (search for “WebRTC leak prevent” compatible with your browser). Configure it to block non-proxied UDP and suppress host candidates.

4.2 Enterprise/managed policy (most robust)

If you manage your browser via policy, set WebRtcIPHandlingPolicy to a restrictive mode for all users. Example JSON for Chromium policies (Windows/Mac/Linux enterprise level):

{ "WebRtcIPHandlingPolicy": "disable_non_proxied_udp", "WebRtcUdpPortRange": "40000-40000" } 

Recommended values for WebRtcIPHandlingPolicy:

• disable_non_proxied_udp — blocks direct UDP paths; forces proxy/VPN paths.
• default_public_interface_only — reduces local IP exposure but may still allow srflx.
• default_public_and_private_interfaces — not recommended for privacy.

On Microsoft Edge, use the equivalent Edge policy via edge://policy after deploying ADMX/JSON.

4.3 Flags & mDNS notes

• Modern Chromium uses mDNS ICE candidates to hide private IPs; keep this enabled (default).
• There is no reliable “--disable-webrtc” switch that safely disables all WebRTC without breaking sites; prefer policy/extension/VPN enforcement.

---

5) Hardening Firefox (desktop & Android)

Firefox gives deep control via about:config. Open a new tab → enter about:config → accept the warning → search and set:

• media.peerconnection.enabled → false (disables WebRTC entirely; breaks WebRTC sites)
• media.peerconnection.ice.no_host → true (hide host candidates)
• media.peerconnection.ice.default_address_only → true (limit candidate addresses)
• media.peerconnection.ice.proxy_only → true (force proxy/VPN path; strong privacy)

For a balanced approach, keep media.peerconnection.enabled = true (so conferencing still works) but set the three ice.* prefs above to limit exposure and force proxied routes.

Android Firefox supports about:config as well — apply the same keys. Test on real sites that need WebRTC (e.g., video calls) to confirm compatibility.

---

6) Hardening Safari (macOS & iOS/iPadOS)

• Safari already masks host candidates via mDNS by default (reduces local IP exposure).
• There’s no supported toggle to “disable WebRTC” globally without breaking functionality. For privacy:
  • Prefer VPN apps that block non-VPN UDP.
  • On macOS, use the firewall recipes to restrict outbound STUN/TURN for browsers.
  • Consider content blockers that suppress known WebRTC JS APIs on non-trusted domains (limited).

On managed Macs, pair VPN enforcement with a pf firewall rule set (below) for strongest guarantees.

---

7) Mobile browsers: iOS & Android practical steps

iOS/iPadOS

• Safari + Chromium-based iOS browsers use the WebKit engine; rely on VPN app settings like “Block non-VPN traffic.”
• For organizational devices, enforce Always-On VPN with per-app VPN and disallow cellular fallback for non-proxied UDP.

Android

• In Android 8+, enable Always-on VPN and Block connections without VPN (Settings → Network & Internet → VPN).
• Firefox for Android: use the about:config prefs shown in the Firefox section.
• Chromium for Android lacks granular WebRTC toggles; rely on the OS VPN enforcement and provider features.

---

8) VPN-side protections (provider features & configs)

Many modern VPN clients ship specific WebRTC leak protections:

• Block non-VPN traffic / Kill switch: Drops any packet not routed through the tunnel (including WebRTC STUN). Enable it.
• Disable non-proxied UDP: Some clients expose this explicitly; it’s ideal for WebRTC privacy.
• DNS over VPN: Prevents DNS leakage (separate from WebRTC but important for privacy posture).
• WireGuard/OpenVPN firewalls: Some clients add host firewall rules while connected; keep them active.

Provider selection tips:

• Choose a vendor that documents WebRTC leak mitigation and offers a robust kill switch.
• Prefer clients with per-SSID trust lists (e.g., stricter modes on public Wi-Fi).
• Verify post-connect with BrowserLeaks and ipleak.net.

---

9) OS-level controls: Windows/macOS/Linux firewall recipes

Warning: Blocking STUN/TURN ports can break legitimate video/voice apps. Prefer policy-based or interface-scoped rules that only block on non-VPN interfaces.

9.1 Windows 10/11 (Advanced Firewall, interface-scoped)

Common STUN/TURN ports: 3478/udp, 5349/tcp, Google STUN: 19302-19309/udp. Create Outbound rules that block these on Private/Public profiles but not on the VPN adapter (many VPNs set a distinct Interface Type or Network Category).

# PowerShell (run as Administrator) # Example: block common STUN UDP ports for all profiles New-NetFirewallRule -DisplayName "Block STUN UDP 3478" -Direction Outbound -Action Block -Protocol UDP -RemotePort 3478 New-NetFirewallRule -DisplayName "Block Google STUN 19302-19309 UDP" -Direction Outbound -Action Block -Protocol UDP -RemotePort 19302-19309
Optionally scope to non-VPN interfaces by InterfaceAlias
(Replace Wi-Fi/Ethernet with your non-VPN aliases)

New-NetFirewallRule -DisplayName "Block STUN on Wi-Fi" -Direction Outbound -Action Block -Protocol UDP -RemotePort 3478 -InterfaceAlias "Wi-Fi"

Better: Some VPN clients expose a Windows Filtering Platform (WFP) component that already blocks non-tunneled UDP. Use the client’s kill switch instead of manual port lists when possible.

9.2 macOS (pf packet filter)

Create a small pf anchor that blocks common STUN UDP ports on non-VPN interfaces. Identify your VPN interface (e.g., utun2) via ifconfig. The example below blocks on all except the VPN interface:

# /etc/pf.anchors/webrtc_block.conf # Block common STUN/Google STUN ports on non-VPN interfaces table <stun_ports> { 3478, 19302:19309 } block out quick on ! utun2 proto udp from any to any port <stun_ports>
Load rules

sudo pfctl -f /etc/pf.conf
sudo pfctl -a com.local.webrtc -f /etc/pf.anchors/webrtc_block.conf
sudo pfctl -e # enable pf if not already

Ensure your main /etc/pf.conf includes:

anchor "com.local.webrtc" load anchor "com.local.webrtc" from "/etc/pf.anchors/webrtc_block.conf" 

Revert if conferencing breaks. You can narrow to browsers by using pfctl with owner matching (limited) or app firewalls (LuLu/Little Snitch) to block browser UDP on those ports when the VPN isn’t present.

9.3 Linux (nftables)

sudo nft add table inet filter sudo nft add chain inet filter output { type filter hook output priority 0 \; } # Assume vpn0 is your VPN interface; block STUN on others sudo nft add rule inet filter output oifname != "vpn0" udp dport {3478, 19302-19309} counter drop 

Persist via your distro’s nftables service. As with macOS, expect breakage for RTC apps on non-VPN networks.

---

10) Network-level defenses (home/office gateways)

• DNS filtering: Use resolvers that block known STUN trackers (limited effect; many apps hardcode IPs).
• Firewall egress policies: On routers like pfSense/OPNsense, block outbound UDP 3478/19302-19309 for VLANs where you want strict privacy. Allow from the VPN interface only.
• Per-SSID policies: For guest Wi-Fi, restrict outbound UDP except to the VPN concentrator to force all WebRTC over VPN/relay.

---

11) Troubleshooting & validation workflow

1. Baseline: Connect VPN → visit BrowserLeaks WebRTC and ipleak.net. If you see your real ISP IP under WebRTC, you’re leaking.
2. Apply browser policy: Set Chrome/Edge policy disable_non_proxied_udp or Firefox ice.proxy_only. Retest.
3. Enable VPN safeguards: Kill switch / block non-VPN traffic. Retest.
4. OS firewall (optional): Add interface-scoped STUN blocks. Retest WebRTC and your conferencing app.
5. Inspect candidates: Chromium chrome://webrtc-internals → ensure relay or VPN-path candidates only; avoid srflx showing ISP IP.
6. Packet capture (advanced): Wireshark filter stun or udp.port == 3478; confirm egress on VPN interface.

---

12) FAQ: Blocking WebRTC Leaks When Using a VPN

Does mDNS completely solve WebRTC leaks?

No. mDNS obfuscates local IP (host candidates) but not public srflx candidates. You still need to prevent non-proxied UDP to STUN servers.

Can I just disable WebRTC entirely?

In Firefox you can (media.peerconnection.enabled=false). In Chromium, “fully disable” isn’t supported without breaking sites/extensions. Prefer policies/extensions that block non-proxied UDP and restrict candidate exposure.

Will blocking STUN ports break Zoom/Meet/Teams?

Potentially. Those apps may require STUN/TURN. Use interface-scoped rules (block on non-VPN interfaces) or allow only your TURN/VPN paths.

Is a “kill switch” the same as WebRTC leak protection?

Not exactly, but a good kill switch that blocks non-VPN traffic will also stop non-proxied UDP (and thus most WebRTC leaks). Verify with the test sites.

Why do I still see an IP after hardening?

If the IP belongs to your VPN exit or a TURN relay, that’s expected. The problem is seeing your real ISP IP (outside the tunnel).

13) Summary

WebRTC leaks happen when the browser exposes srflx candidates from STUN over non-proxied UDP while your VPN is active. The fix is layered: (1) enforce browser policies (or Firefox prefs) to restrict ICE; (2) enable VPN “block non-VPN traffic”; (3) optionally add OS/router firewall rules that deny STUN on non-VPN interfaces; and (4) validate on BrowserLeaks and ipleak.net. Done right, your WebRTC candidates will either be relay (TURN) or reflect your VPN exit—never your ISP IP.