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

Setup	WebRTC 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 mode	No — 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!
└──────────────┘         └──────────────┘

---

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):

Port	Protocol	Used by
3478	STUN / TURN	All browsers, most VoIP apps
5349	STUN / TURN over TLS	Fallback for the above
19302	STUN	Google’s public STUN servers (stun.l.google.com)

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:

/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:

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

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.

Router	Where to configure
pfSense / OPNsense	Firewall → 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 filtering	Not possible — use the per-browser fixes below

---

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

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:

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

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

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

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

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.