Author: Clodo

Posted on Reddit here: http://redd.it/32d94q

Recently there were a lot of discussions about the WebRTC IP Leak. Almost all of them are talking about a “Security flaw” or treat it as a bug.

However, many articles about the WebRTC [leaks] talk about a solution: disable WebRTC in favorite browser.
Two questions:

• Is it really a “Security flaw” that needs to be fixed in browsers? Look at browsers bug-reports to understand how many different opinions exist on this.
• Why the browser can go outside the VPN tunnel? How many app/protocols can do the same things of the WebRTC leak? So, is disabling WebRTC a sufficient solution for those who use a VPN to avoid exposing their ISP IP address or traffic?

I will explain details of the issue. But first, if you are connected to a VPN service right now, try this:

ipdetection.zip (source available here )

or, under Unix try this (try also as root):

for s in `ifconfig -a | sed 's/[ \t].*//;/^\(lo\|\)$/d'`; do curl --interface $s http://www.clodo.it/projects/whatismyip/; done

Is your real ISP IP leaked?

Details

When a user connects to OpenVPN, the main interface (ethernet, wifi etc) is still available (also to talk with the VPN server itself).
And another network interface is opened (tun/tap).
This is the scope of OpenVPN: create a tunnel.

As a plus, OpenVPN can be configured to push a directive from the server to their client: “redirect-gateway”.
This tells at client-side that ALL traffic needs to be redirected inside the tunnel by default.

Almost all VPN services use a specific option of that directive: “redirect-gateway def1”.
From OpenVPN manual

def1 — Use this flag to override the default gateway by using 0.0.0.0/1 and 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of overriding but not wiping out the original default gateway.

Now, this means that the original 0.0.0.0/0 route are still active, but there are other routes created by OpenVPN that override the original based on precedence.
But 0.0.0.0/0 is a route assigned to the standard interface, while the new 0.0.0.0/1 and 128.0.0.0/1 are assigned to the TUN interface.

In every OS, when a connection/socket is opened, the program can choose a specific network interface that needs to be used.
This is not common, because most applications don’t need that and let the OS use the default network interface.

The program above do exactly this: bind to specific network interface to query an external what is my ip address service.
When binding to the standard interface, the overriding rules of OpenVPN are simply ignored, at least under Windows.

I think browsers do the same thing in WebRTC discovery.

Can a VPN service based on OpenVPN resolve the issue server-side, transparently to their users?

Yes.
Simply don’t use the def1 option in redirect-gateway directive.
Without def1, OpenVPN client removes totally the 0.0.0.0/0 route, and re-creates it at disconnection.

But I don’t recommend this approach: with def1, if the OpenVPN process is terminated, the overriding routes are automatically deleted or unused, and traffic continues to flow over the standard interface.
Without def1, if OpenVPN process is killed/terminated, the user remains without any route for his/her traffic.

For me, a good VPN service needs to use the def1 option, for the final consideration below.

Final consideration

WebRTC IP Leak is not a fault of browsers.

It is not a fault of OpenVPN (that is designed to be a Tunneling software, not an Always hide my traffic software).

It is a fault of users, because they trust the standard OpenVPN client for things out of its scope, or trust a badly-written VPN service client software.

Users need to use a VPN service that has a software addressing this kind of issue, or need to understand how to configure a firewall or a router.

*Disclaimer: *
I’m the author of the client software of a known VPN service. Anyway I don’t cite it in this reddit.