How to Configure WebRTC IP Handling Policy, STUN/TURN Leak Protection, and Media Device Permissions in Google Chrome

Architectural Foundation of WebRTC and Network Interface Leaks

Web Real-Time Communication (WebRTC) is an open-source framework and W3C standard that enables peer-to-peer (P2P) video streaming, voice conferencing, and direct data exchange within web browsers without external third-party plugins. To establish direct low-latency P2P sockets across symmetric and asymmetric Network Address Translation (NAT) gateways, WebRTC relies on the Interactive Connectivity Establishment (ICE) framework, which queries STUN (Session Traversal Utilities for NAT) and TURN (Traversal Using Relays around NAT) servers.

During the ICE candidate gathering phase, the browser audits all physical and virtual network interfaces attached to the operating system. Even when a workstation routes general internet traffic through an encrypted Virtual Private Network (VPN) tunnel or an enterprise HTTP proxy, WebRTC’s default behavior sends STUN binding requests across all available network routes—including local physical Ethernet interfaces, Wi-Fi adapters, and cellular radios. Consequently, remote web servers executing malicious JavaScript can enumerate private LAN IP addresses (e.g., 192.168.1.105) and the true, non-proxied public IPv4/IPv6 addresses assigned by the user’s Internet Service Provider (ISP), completely circumventing VPN privacy protections.

WebRTC IP Handling Policy	Network Routing Behaviour	VPN Leak Risk	Peer-to-Peer Connection Performance
default	Probes all local & public interfaces via STUN simultaneously	High (Bypasses VPN tunnel interfaces)	Optimal (Lowest possible P2P latency)
default_public_and_private_interfaces	Probes default public interface + default local route	Moderate (Exposes local LAN IP address)	Good (Standard NAT traversal)
default_public_interface_only	Uses only default route; binds public VPN IP, suppresses LAN IPs	Low (Protects private internal subnets)	Acceptable (May fail on complex multi-NAT LANs)
disable_non_proxied_udp	Forces WebRTC through proxy or TURN relay; blocks non-proxied UDP	Zero (Complete VPN / proxy leak immunity)	Reduced (Traffic relayed via TURN servers; higher latency)

Deploying Enterprise WebRTC Policies via Windows Registry and Chrome Policies

In managed enterprise environments and privacy-conscious workstations, administrators enforce the WebRtcIPHandlingPolicy directly through operating system policy stores, preventing end-user alteration or extension bypass.

Step 1: Enforcing Policies via PowerShell on Windows

# Create the Google Chrome enterprise policy registry path
New-Item -Path "HKLM:\SOFTWARE\Policies\Google\Chrome" -Force | Out-Null

# Set WebRTC IP Handling Policy to 'disable_non_proxied_udp'
# This completely blocks UDP traffic that does not traverse the active VPN/proxy tunnel:
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Google\Chrome" `
    -Name "WebRtcIPHandlingPolicy" `
    -Value "disable_non_proxied_udp" `
    -Type String

# Enforce camera and microphone permission restrictions
# Prevent unauthorized origins from probing media device enumerations:
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Google\Chrome" `
    -Name "DefaultWebRtcAllowRadioStateChanges" `
    -Value 0 `
    -Type DWord

Step 2: Enforcing Policies on macOS via Configuration Profiles

On macOS, administrators deploy a mobile device management (MDM) property list or write directly to defaults under the com.google.Chrome domain:

# Write enterprise policy to Chrome preference domain
sudo defaults write /Library/Preferences/com.google.Chrome.plist WebRtcIPHandlingPolicy -string "disable_non_proxied_udp"

# Verify policy registration in Chrome
defaults read /Library/Preferences/com.google.Chrome.plist WebRtcIPHandlingPolicy

Configuring WebRTC Privacy via the Chrome Privacy API

For standalone users operating without administrative domain controllers, WebRTC privacy extensions leverage the native chrome.privacy.network JavaScript API. This mechanism programmatically reconfigures the browser’s underlying ICE candidate generation engine:

// Background service worker implementation in Manifest V3 extension
chrome.runtime.onInstalled.addListener(() => {
    chrome.privacy.network.webRTCIPHandlingPolicy.set(
        {
            value: 'disable_non_proxied_udp',
            scope: 'regular'
        },
        () => {
            if (chrome.runtime.lastError) {
                console.error("Policy configuration error:", chrome.runtime.lastError);
            } else {
                console.log("WebRTC IP Handling Policy locked to 'disable_non_proxied_udp'");
            }
        }
    );
});

Auditing and Testing WebRTC Leaks via chrome://webrtc-internals

To verify that physical IP addresses and non-proxied routes are no longer exposed to web applications, audit the internal diagnostics engine provided by Chrome.

1. Navigate to chrome://policy in the Chrome address bar. Verify that WebRtcIPHandlingPolicy appears under Google Chrome Policies with its value set to disable_non_proxied_udp or default_public_interface_only.
2. Open a new tab and navigate to chrome://webrtc-internals. This diagnostic surface records all active peer connections, media streams, and ICE candidates in real time.
3. In a separate tab, open a WebRTC communication client (such as Google Meet or a WebRTC leak testing harness).
4. Return to chrome://webrtc-internals and expand the IceCandidate table.
5. Inspect the candidate strings:
   • Leaked State: Entries displaying typ host followed by your local LAN IP (e.g., 192.168.1.x) or true ISP public IP.
   • Secured State: Host candidates reflect only the assigned VPN virtual adapter IP, or entries exclusively report typ relay routed via an encrypted TURN endpoint over TCP/TLS.

Managing Media Device Permissions and Preventing Device Fingerprinting

Beyond network IP address leakage, the WebRTC navigator.mediaDevices.enumerateDevices() API allows web origins to enumerate hardware identifiers—such as audio input microphones, video cameras, and audio output speakers. These unique hardware labels can be combined with browser entropy to generate persistent cross-site tracking fingerprints.

Step 1: Enforce Strict Media Sandboxing

1. Navigate to Settings > Privacy and security > Site settings.
2. Under the Permissions section, select Camera.
3. Select Don’t allow sites to see your camera. Repeat this configuration for Microphone.
4. When visiting legitimate conferencing portals (such as Google Meet or Microsoft Teams), click the lock/settings icon in the address bar and grant transient, per-site permissions.

Troubleshooting WebRTC and Policy Configuration Faults

Observed Issue	Probable Root Cause	Technical Diagnostic Method	Remediation Protocol
Google Meet Fails to Connect (Call Drops)	disable_non_proxied_udp active on network where corporate firewall blocks UDP/TCP relays	Inspect chrome://webrtc-internals; check for failed ICE connection state	Adjust policy to default_public_interface_only to permit direct UDP across default route
Local LAN IP Visible in Leak Tests	Policy set to default_public_and_private_interfaces or mDNS obfuscation disabled	Review candidate strings for local IP addresses	Set policy strictly to default_public_interface_only or disable_non_proxied_udp
WebRTC Extension Cannot Modify Policy	Operating system Enterprise Policy (GPO/Registry) takes precedence over Extension API	Inspect chrome://policy for precedence hierarchy	Remove conflicting GPO key in Registry or adjust master enterprise policy directly
High Call Latency / Robotic Audio	WebRTC forced to relay all media through distant TURN relay servers over TCP	Inspect RTT (Round Trip Time) metrics in chrome://webrtc-internals	Permit outbound UDP on port 443/3478 to trusted TURN endpoints on corporate perimeter firewall
Microphone Not Detected in Conferencing Apps	Media device enumeration blocked at system permission layer (OS-level sandboxing)	Check Windows Settings > Privacy > Microphone permissions	Ensure “Allow desktop apps to access your microphone” is enabled in operating system settings