webrtc private ip leak.

[kbps 26]

Using OpenVPN on Android I have a webrtc leak showing two private 10.4.x.x and 10.42.x.x ip's that my cellular provider must be allocating me. Am I right in thinking that this is not a major problem because they are in the private ip range and not the public facing address?

[zhang888 1065]

The entire WebRTC leak thing was very overhyped over the past year, and many less-honest VPN providers jumped aboard and used this is a marketing/sales pitch.

In reality, if you are connected to the VPN already, and your WebRTC test reports 10.4.x.x IP (which is probably Air's internal IP) there is nothing bad in that.

 

The problem arises in very rare cases, when no NAT device is present, for example when you connect an ethernet port from your cable modem to your LAN adapter directly,

and your ISP assings you public IPs by defailt. In this case, your reported WebRTC IP would be not internal, but external, potentially exposing your original IP address.

But this setup is very rare these days, most people have Wi-Fi's, which automatically implies usage of a router with NAT mechanism.

 

The danger of growing Mobile ISPs that assign routable IPv6 addresses, which all VPN providers not yet support, is much higher than WebRTC.

[Valerian 20]

That can't be right. I'm behind a router, and if I disable Network Lock then ipleak.net shows the IP assigned by my ISP.

[me.moo@posteo.me 80]

The 10.xx will be your Airvpn IP and DNS addresses and useless to anyone else.

 

oops, just noticed i'm not replying to the OP in which case I apologise.

Edited ... by MeAndroid

[kbps 26]

The 10.xx will be your Airvpn IP and DNS addresses and useless to anyone else.

 

oops, just noticed i'm not replying to the OP in which case I apologise.

Thanks that what I though.

 

 

That can't be right. I'm behind a router, and if I disable Network Lock then ipleak.net shows the IP assigned by my ISP.

Im using Airvpn via OpenVPN on Android, so I don't have this option.  Also for chrome browser on Android, plugins are not available so I can't use them to stop the leak.

[Valerian 20]

Sorry, my comment was in reply to zhang888's post.

[Staff 9748]

 

The problem arises in very rare cases, when no NAT device is present, for example when you connect an ethernet port from your cable modem to your LAN adapter directly,

and your ISP assings you public IPs by defailt. In this case, your reported WebRTC IP would be not internal, but external, potentially exposing your original IP address.

But this setup is very rare these days, most people have Wi-Fi's, which automatically implies usage of a router with NAT mechanism.

 

Nissemus is right, the external, public IP address is immediately found even if you're behind a NAT. The application binds to the physical interface which sends packets outside the tunnel to the router which routes them in the usual ISP route. The receiver that asked for STUN service will receive packets coming from the customer real IP address.

 

Network Lock will of course prevent this, as you know, just like it drops any other packet out of the tunnel coming (for example) from processes binding to the physical interface.

 

As a side note, see also how STUN is able to traverse NAT:

https://webrtchacks.com/stun-helps-webrtc-traverse-nats/

 

 

Kind regards