WebRTC and wintun: Is it safe?

[pfolk 6]

I've tested 2.18.9, 2.19.1 beta and 2.19.2 beta all with wintun driver (on Win 10), which increased/doubled speed.

but I see now in tests on ipleak.net in the "Your IP addresses - WebRTC detection" section, that a Private-Use - [RFC1918] address as well as a IETF Protocol Assignments - [RFC2928] address is listed

Neither one matches my ISP address, but wondering why that is ?

Btw, this only happens when checking ipleak.net in Chrome - in Firefox (on same machine), the "Your IP addresses - WebRTC detection" section is empty.

On other machines running standard TAP driver in AirVPN, the "Your IP addresses - WebRTC detection" section is always empty, whether in Firefox or Chrome.

Is the above because of the Wintun driver and/or is this a security problem ?

[OpenSourcerer 1435]

1 hour ago, pfolk said:

Is the above because of the Wintun driver and/or is this a security problem ?

That is a browser problem, as you demonstrated here:

1 hour ago, pfolk said:

Btw, this only happens when checking ipleak.net in Chrome - in Firefox (on same machine), the "Your IP addresses - WebRTC detection" section is empty.

It's not possible to directly disable WebRTC in Chrome like it is in Firefox. Extensions blocking the protocol must be used for this.

[pfolk 6]

5 hours ago, giganerd said:

It's not possible to directly disable WebRTC in Chrome like it is in Firefox. Extensions blocking the protocol must be used for this.

is it a security problem ?

[OpenSourcerer 1435]

3 hours ago, pfolk said:

is it a security problem ? 

Not at all. WebRTC is actually quite useful for direct client-to-client applications like video conferencing without the use of plugins and central servers. But in a VPN setting it can bypass the tunnel and lead to a leak of your ISP IP address, which is not exactly desirable.

[pfolk 6]

13 hours ago, giganerd said:

Not at all. WebRTC is actually quite useful for direct client-to-client applications like video conferencing without the use of plugins and central servers. But in a VPN setting it can bypass the tunnel and lead to a leak of your ISP IP address, which is not exactly desirable.

got ya, makes sense. but if ipleak only reports the local IP, e.g. 192.168.2.x, but not the ISP IP, then I assume we're anonymous ?

[pfolk 6]

makes me think that maybe ipleak should offer a service to check for leaks via a general curl request ( issued from command line), to circumvent differences in browsers and do all checks on the general internet connection...

[OpenSourcerer 1435]

12 minutes ago, pfolk said:

got ya, makes sense. but if ipleak only reports the local IP, e.g. 192.168.2.x, but not the ISP IP, then I assume we're anonymous ?

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.
 

22 minutes ago, pfolk said:

makes me think that maybe ipleak should offer a service to check for leaks via a general curl request ( issued from command line), to circumvent differences in browsers and do all checks on the general internet connection... 

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.

[pfolk 6]

6 hours ago, giganerd said:

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.

so, trying to understand this. When a browser (Chrome in this case) reveals my local IP in ipleak.net (because of WebRTC), then it is NOT connected through the VPN tunnel ? meaning: any usage of Chrome (in this example) including possibly downloads (via the browser) or whatever would be non-anonymous ?

and by the same logic, if another browser (e.g. Firefox) does not reveal any other IP in ipleak.net other than the AirVPN exit node's IP then it would be safe to use as it is connected through the VPN tunnel only ?

can you expand on WebRTC ? Is this a browser specific protocol/standard ? or does it also come into play in general http related downloads that are not done via the browser ?

Thanks !

[OpenSourcerer 1435]

I split our conversation from the original location to a separate thread, we were conversing off-topic there.
 

2 hours ago, pfolk said:

so, trying to understand this. When a browser (Chrome in this case) reveals my local IP in ipleak.net (because of WebRTC), then it is NOT connected through the VPN tunnel ? meaning: any usage of Chrome (in this example) including possibly downloads (via the browser) or whatever would be non-anonymous ?

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.
 

3 hours ago, pfolk said:

can you expand on WebRTC ? Is this a browser specific protocol/standard ? or does it also come into play in general http related downloads that are not done via the browser ?

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.

[pfolk 6]

1 hour ago, giganerd said:

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.

Thank you for the explanation, I (think) I got it except the quoted text. so Eddie had Network lock enabled, yet Chrome with WebRTC showed my local IP... so was the network not fully locked or what am I missing ?

Thanks, good stuff !

[OpenSourcerer 1435]

31 minutes ago, pfolk said:

so Eddie had Network lock enabled, yet Chrome with WebRTC showed my local IP

The 192.168.x.x one? If it shows a 10.x.x.x, it's the local one from AirVPN. This on the other hand is okay, NetLock blocks everything outside the tunnel and 10.x.x.x is not.

[pfolk 6]

On 4/27/2020 at 3:36 AM, giganerd said:

The 192.168.x.x one? If it shows a 10.x.x.x, it's the local one from AirVPN. This on the other hand is okay, NetLock blocks everything outside the tunnel and 10.x.x.x is not.

wanna follow up with another question I have in regards to the ipleak.net results:

under the SERVER section it seems to be running ~ 100 tests and sometimes it shows that it has occurred errors - but it does not state what the errors are. I usually connect to a different server, run the tests again and if no errors then use that server.

but can somebody comment on whether these unspecified errors are a potential security problem ?

[OpenSourcerer 1435]

11 hours ago, pfolk said:

under the SERVER section it seems to be running ~ 100 tests and sometimes it shows that it has occurred errors - but it does not state what the errors are. I usually connect to a different server, run the tests again and if no errors then use that server.

What this test does is connect to xyz.dns.ipeak.net many times and note which DNS server resolved each of the requests. xyz here is a 40 characters long string which is randomized. This way one can detect most if not all used DNS servers.
The randomization is done to avoid DNS caching – otherwise we'd only get shown what the fastest request resolved to. In other words: First request goes out to the net and for the other 99 connections the DNS resolver would reply "hey, I remember this name, here's the address I got earlier".

If you get an error, it can have a multitude of reasons.

• The request couldn't be made because of a firewall or so.
• The request was made but you got a HTTP 4xx or 5xx code back. Can happen if there are temporary problems, but seeing as it's a constant thing for you, it's quite unlikely.
• Some of your configured DNS servers did not return a usable result (like NXDOMAIN or SERVFAIL, probably NODATA as well) or simply timed out (if some of those tests took their time). May be the most likely explanation.

Any errors are not a security problem per se; they have nothing to do with server security. You can use all servers showing this without compromise. When using them it can mean occasional waiting times when resolving something, but if you didn't experience it so far, it won't happen.