How to Configure Strict WebRTC IP Handling Policy in Google Chrome

Web Real-Time Communication (WebRTC) enables direct, peer-to-peer audio, video, and data streaming within web applications without third-party plugins. However, the Interactive Connectivity Establishment (ICE) framework utilized by WebRTC gathers all available network interface addresses—including local RFC 1918 private IPs and underlying ISP public IPs—to discover the shortest routing path. Even when browsing through a Virtual Private Network (VPN) or proxy, rogue websites can execute WebRTC STUN requests to harvest your true physical IP address. Configuring strict WebRTC IP handling policies in Google Chrome eliminates these IP leakage vectors.

Understanding WebRTC ICE Candidate Discovery

WebRTC discovers connection routes by generating multiple candidate tiers:

• Host Candidates: Local network interface addresses (e.g., 192.168.1.50), exposing internal network topology.
• Server Reflexive Candidates (STUN): The client’s public-facing WAN IP address as perceived by external STUN servers. If your VPN operates outside the browser network socket, STUN requests bypass the tunnel and reveal your ISP origin.
• Relay Candidates (TURN): Media relayed through intermediate proxy servers, which conceals physical client IP addresses completely.

Configuring WebRTC IP Handling Policy via Chrome Enterprise Policy

The Chromium engine provides four distinct WebRTC IP handling tiers via the WebRtcIPHandlingPolicy policy:

• default: Standard WebRTC behavior; gathers all local and public interfaces.
• default_public_and_private_interfaces: Uses default route interfaces, but conceals non-default multihomed adapters.
• default_public_interface_only: Gathers only the public interface bound to the default gateway, stripping local private IP details.
• disable_non_proxied_udp: Strict Security Mode. Restricts WebRTC traffic entirely to TCP or through active proxy connections, dropping unproxied UDP STUN queries to prevent IP leaks.

Applying the Strict Policy in Windows 11 via PowerShell

Configure the strict WebRTC IP handling policy in the Windows Registry using PowerShell:

# Registry path for Google Chrome Enterprise Policies
$regPath = "HKLM:\SOFTWARE\Policies\Google\Chrome"
if (-not (Test-Path $regPath)) {
    New-Item -Path $regPath -Force | Out-Null
}

# Enforce strict policy: disable non-proxied UDP to stop VPN leakage
Set-ItemProperty -Path $regPath -Name "WebRtcIPHandlingPolicy" -Value "disable_non_proxied_udp"

Write-Output "Chrome WebRTC IP Handling Policy set to: disable_non_proxied_udp"

Verifying Policy Enforcement in chrome://policy

Confirm that the policy has applied cleanly across the browser:

1. Open Google Chrome, type chrome://policy into the Omnibox, and press Enter.
2. Click Reload policies at the top of the interface.
3. Search for WebRtcIPHandlingPolicy:
   • Verify that Status reports OK.
   • Confirm that Value displays "disable_non_proxied_udp" or "default_public_interface_only".

Testing for WebRTC IP Leaks in Chrome DevTools

Validate that candidate harvesting is strictly contained:

1. Navigate to a WebRTC leak test portal (such as https://browserleaks.com/webrtc).
2. Inspect the reported candidate list:
   • Local IP Addresses: Must display Disabled or mDNS masked (e.g., [uuid].local).
   • Public IP Address: Must strictly match your active VPN or proxy gateway rather than your underlying ISP connection.
3. Open Chrome DevTools (Ctrl + Shift + I) and navigate to chrome://webrtc-internals in a separate tab to review granular ICE candidate generation logs.

Balancing Privacy and Streaming Quality

While disable_non_proxied_udp provides absolute leakage immunity, pure TCP fallback can introduce slight latency during peer-to-peer video calls on slow networks. For typical home setups using VPNs with native UDP routing, default_public_interface_only offers an optimal compromise by eliminating private LAN leaks while retaining fast UDP streaming.