[JoshTriplett]

It seems like the problem that WebRTC wants to solve could be solved another way, by putting more of the discovery logic into the browser rather than the application. WebRTC wants to find peers on the local LAN, and communicate with them directly. Why not let the browser find peers, and then hand the WebRTC application a connection without exposing where that connection leads?

That said, long-term, I think networks need to stop treating non-routability alone as a firewall mechanism. Any information that this WebRTC mechanism reveals could also be exploited by any random client application, or in the case of http-based protocols, by anyone who can embed an iframe or submit a form. Consider how you'd design a network in which every device had a routable IP address, and go ahead and design it that way anyway as a defense-in-depth measure. Use encrypted and authenticated protocols even on your "private" network.

[arkitectual]

The problem is that in order for WebRTC to work correctly for all use cases all local IPs must be sent to the remote client.

One example would be if you happened to use WebRTC with two peers on the same VPN.

[juberti]

We have added an initial solution for this issue in Chrome 42. Users can set the following preference:

"webrtc": { "multiple_routes_enabled": false },

For the location of the prefs file, see http://www.chromium.org/administrators/configuring-other-pre....

This forces all WebRTC connections to only use server-reflexive and relay ICE candidates, and only on the default IP route. While this may cause a QoS hit (two users behind NAT can no longer keep their traffic internal to the NAT), it does allow the issue mentioned here to be fully addressed without disabling WebRTC altogether.

[Golgi_SDK]

Thanks very much for your reply. I've been trying to enable the preference in Google Chrome Canary on Mac OSX. However, I haven't been able to successfully block the IP leak - I suspect because I haven't configured it correctly. I had to manually create the file "/Library/Google/Google Chrome Master Preferences" and add the setting you suggested. I then reinstalled Chrome Canary and tested but no effect. I also tried editing the user preferences file in ~/Library/Application\ Support/Google/Chrome\ Canary/Default/Preference but that seems to be overwritten by the browser. How should I be configuring this preference? Thanks again.

[JoshTriplett]

That doesn't necessarily mean they need to be sent to the server. The two browsers on the same LAN could coordinate via local discovery, establish a socket between themselves, hand that socket to WebRTC, and never tell the two applications running in the browser sandbox what local LAN IPs they use.