Leaderboard

I split our conversation from the original location to a separate thread, we were conversing off-topic there. No. Don't think of the application level here, the reason is strictly networking-related. There is a thing called kernel routing table, it's a table with routing rules for the OS. Depending on the destination you want to reach, a route is chosen based on its existence and metric (read: rank). When you connect with OpenVPN, you might be as far as knowing that routes are created with a lower metric (read: higher rank) so that your OS will prefer the route over the VPN interface. What you might not know is that OpenVPN does not replace or delete any routes (unless explicitly configured to do so), so the route to your local network is still there, and this one goes through the physical interface. Also important to know is that a connection to OpenVPN does not miraculously block any application from using other interfaces with other routes, and exactly this poses the risk with WebRTC behind a VPN: It will eventually try a connection on all of them, and if it's done on the physical interface, the connection will go out from your router's public IP, therefore ISP IP. The only way to stop it from doing that is to use a firewall (like Eddie does with NetLock) or to simply disable WebRTC in the browsers. It is independent from whatever you do in the browsers. There you connect to a destination and since the VPN route is to be preferred, the connection will go via the VPN interface. WebRTC is a general standard and in principle can be used anywhere, but it was predominantly made for browsers. And no, HTTP is another protocol altogether.

No, that's exactly the problem. It may take the best route for 192.168.2.x according to the kernel routing table of the OS (because your local network range is excluded from the tunnel by default in OpenVPN), which means it won't connect through the tunnel, and therefore it will connect with your ISP IP, effectively revealing it to the peer. If one wants WebRTC to work over the tunnel, OpenVPN must replace the default route. But this kills connectivity to all the devices in the local network, safe for the router, maybe. It's already available for IP and DNS tests using the IPLeak API, though DNS detection must be scripted to match the functionality you'd see in the browser:WebRTC, geolocation and torrent client tests are unavailable, though, for obvious reasons.