Skip to content
rVPN rVPN

WebRTC Leak Prevention

WebRTC lets browsers open direct peer-to-peer connections for voice/video calls and real-time apps. To do that, it must discover your public IP address — and it does so over raw UDP sockets that ignore your proxy settings entirely. Any website can trigger this with a few lines of JavaScript and learn your real IP, even while all your browsing goes through rVPN.

Who Is Affected

Section titled “Who Is Affected”
SetupWebRTC leak?
rVPN apps (iOS, macOS, Android)No — the OS packet tunnel captures UDP; STUN rides the tunnel and reports the exit server’s IP
CLI client in TUN modeNo — all UDP is relayed through the tunnel
CLI client in proxy mode (SOCKS5 / HTTP proxy)Yes — proxies only carry TCP; WebRTC’s UDP goes direct via your ISP

If you run rVPN as a shared proxy on your network (e.g. a gateway box serving SOCKS5/HTTP to the whole LAN), every device using that proxy leaks its real IP via WebRTC unless you close it at the browser or the router.

Proxy mode:
┌──────────────┐         ┌──────────────┐
│ Browser      │ ──────► │ rVPN tunnel  │ ← Web traffic (TCP)
│              │         └──────────────┘
│   WebRTC ────┼───────► │ STUN server  │ ← UDP bypasses proxy. Real IP exposed!
└──────────────┘         └──────────────┘
Section titled “Fix 1: Block STUN at the Router (Recommended)”

Blocking outbound UDP to the STUN/TURN ports makes WebRTC’s IP discovery fail closed for every device on the network at once. Browsers then fall back to proxy-only candidates, and leak tests report nothing.

Ports to block (UDP, LAN → WAN):

PortProtocolUsed by
3478STUN / TURNAll browsers, most VoIP apps
5349STUN / TURN over TLSFallback for the above
19302STUNGoogle’s public STUN servers (stun.l.google.com)

OpenWrt

Section titled “OpenWrt”

SSH into the router and append to /etc/config/firewall:

config rule
    option name 'Block-WebRTC-STUN'
    option src 'lan'
    option dest 'wan'
    option proto 'udp'
    option dest_port '3478 5349 19302'
    option target 'REJECT'
    option enabled '1'

Then apply:

Terminal window
/etc/init.d/firewall reload

Or via LuCI: Network → Firewall → Traffic Rules → Add — source zone lan, destination zone wan, protocol UDP, destination ports 3478 5349 19302, action reject, then Save & Apply.

REJECT (rather than DROP) makes the browser’s STUN probe fail immediately instead of hanging on a timeout.

Verify from any LAN device:

Terminal window
# Should fail fast (connection refused), not hang
nc -u -w2 stun.l.google.com 19302

Other Routers

Section titled “Other Routers”

Any router that can filter outbound traffic by destination port can do the same. Create a rule: source = LAN, destination = WAN/any, protocol = UDP, destination ports = 3478, 5349, 19302, action = reject/deny.

RouterWhere to configure
pfSense / OPNsenseFirewall → Rules → LAN → add block rule for UDP 3478, 5349, 19302
UniFi (UDM/USG)Settings → Firewall → Rules → LAN Out → drop UDP to those ports
MikroTik (RouterOS)/ip firewall filter add chain=forward protocol=udp dst-port=3478,5349,19302 out-interface-list=WAN action=reject reject-with=icmp-port-unreachable
ASUS (stock/Merlin)Firewall → Network Services Filter → block UDP 3478:5349, 19302 for LAN
Consumer router without port filteringNot possible — use the per-browser fixes below

Fix 2: Per-Browser Settings

Section titled “Fix 2: Per-Browser Settings”

Use these when you can’t touch the router, or as a second layer on your own machines.

Chrome / Edge / Brave

Section titled “Chrome / Edge / Brave”

Force WebRTC to only use proxy-routable paths (the “disable non-proxied UDP” policy). With this set, STUN simply fails when no full tunnel is present.

macOS:

Terminal window
defaults write com.google.Chrome WebRtcIPHandling -string "disable_non_proxied_udp"

(For Edge: com.microsoft.Edge; Brave: com.brave.Browser.) Restart the browser afterwards.

Windows (Registry, run as Administrator):

reg add "HKLM\SOFTWARE\Policies\Google\Chrome" /v WebRtcIPHandling /t REG_SZ /d disable_non_proxied_udp

Linux: create /etc/opt/chrome/policies/managed/webrtc.json:

{ "WebRtcIPHandling": "disable_non_proxied_udp" }

Extension alternative: uBlock Origin → Settings → Prevent WebRTC from leaking local IP addresses, or the WebRTC Leak Prevent extension.

Firefox

Section titled “Firefox”

about:config → set media.peerconnection.enabled to false. This disables WebRTC entirely (voice/video calling in the browser will stop working).

For a less drastic option, set media.peerconnection.ice.proxy_only to true — WebRTC stays functional but only ever uses the proxy path.

Safari

Section titled “Safari”

Safari has no user-facing toggle. It already hides local IPs behind mDNS by default, but public-IP STUN candidates still leak in proxy mode. On iOS/macOS the rVPN app tunnels UDP anyway; on other networks, use a different browser or the router fix.

Verify the Fix

Section titled “Verify the Fix”

With the VPN connected, visit:

  1. https://browserleaks.com/webrtc
  2. https://ipleak.net

Expected result: Local IP and Public IP both show - / n/a, and the test reports No Leak. If a public IP still appears and it is your real ISP address, the block isn’t effective on that device.

Side Effects

Section titled “Side Effects”

Blocking STUN/TURN UDP means browser-based voice/video calls that need WebRTC may degrade or fail when no full tunnel is present:

  • Some apps fall back to TURN-over-TCP relays (slower, but works through proxies)
  • Others fail outright — which is precisely the “fail closed” behaviour you want from a privacy standpoint

On networks where you need WebRTC calls to work, prefer the rVPN apps or CLI TUN mode over proxy mode: the tunnel carries UDP, so calls work and the exit IP is the VPN’s.