WebRTC IP Leak Detection: From Bug to Feature
WebRTC — Web Real-Time Communication — was designed to enable video calls, file sharing, and peer-to-peer data transfer directly in the browser. To establish these connections, browsers need to discover their own network interfaces and negotiate connectivity with remote peers. This process involves STUN (Session Traversal Utilities for NAT) and TURN (Traversal Using Relays around NAT) servers that help browsers discover their public IP addresses and traverse NAT firewalls.
The side effect is powerful: even when a user connects through a VPN, the browser's WebRTC stack may reveal the real IP address behind the tunnel. This happens because WebRTC ICE (Interactive Connectivity Establishment) candidates include local network interface addresses that the VPN does not mask.
How the Leak Works
When a browser creates an RTCPeerConnection and gathers ICE candidates, it queries STUN servers to discover its public-facing IP. But it also enumerates local network interfaces — including the physical adapter's private IP. If the VPN only tunnels traffic at the IP layer but does not configure the browser's WebRTC stack to use the tunnel interface exclusively, the real IP leaks through the host candidate.
At tracio.ai, we probe this behavior carefully. Our IP Intelligence system creates a controlled STUN request and analyzes the ICE candidates the browser returns. When the public IP from STUN differs from the IP we see at our server, we flag a VPN or proxy. When the local interface IP reveals a private network range that contradicts the supposed geographic location, we increase the suspect score.
From Bug to Detection Signal
Most privacy-focused browsers have patched this leak — Chrome requires explicit user permission for WebRTC, and Firefox offers settings to disable non-proxied UDP. But the arms race continues: some VPN clients do not properly configure WebRTC, older browser versions remain vulnerable, and the behavioral pattern of a "patched" vs "leaking" WebRTC response is itself a useful signal.
Our approach treats the WebRTC response as a composite signal: the presence of host candidates, the number of ICE candidates returned, the types of candidates (host, srflx, relay), and the response timing all contribute to the device fingerprint. Even when no IP leaks, the pattern of WebRTC behavior is distinctive.
TURN Server Probing
Beyond STUN, we also probe TURN server behavior. TURN relays are typically used when direct peer-to-peer connections fail — common in corporate networks behind strict firewalls. The TURN allocation response reveals information about the relay path: the transport protocol (UDP vs TCP vs TLS), the relay address, and the allocation lifetime.
Our SignalProbe system sends carefully crafted TURN allocation requests to our own relay servers. The response time, supported transports, and allocation success/failure patterns vary by network environment and provide additional signal diversity for device fingerprinting.
Privacy Considerations
We want to be clear: tracio.ai does not exploit WebRTC leaks to deanonymize users. Our system detects when a VPN is in use and reports this as a risk signal. We never store or expose the leaked IP address. The signal is binary: "VPN detected with WebRTC inconsistency" or "WebRTC behavior consistent with direct connection."
This approach gives fraud prevention teams the information they need — a visitor is masking their real location — without compromising individual privacy. The signal helps detect coordinated fraud attacks where multiple accounts originate from the same hidden location.