WebRTC used to reveal real IP address

[go558a83nk 290]

See https://diafygi.github.io/webrtc-ips/

without noscript this site did indeed see my real WAN IP address.

I you're using Firefox, set 'media.peerconnection.enabled' to false to prevent it.

[sheivoko 185]

Nice tip! This also serves as a good test of your firewall setup. On a properly firewalled system, this test will reveal all your LAN, but not WAN addresses.

[Artful Dodger 23]

If using Chromium add the extension WebRTC Block 

[go558a83nk 290]

Nice tip! This also serves as a good test of your firewall setup. On a properly firewalled system, this test will reveal all your LAN, but not WAN addresses.

 

can you please explain more about a firewall setup that would prevent them from seeing the WAN address?

[sheivoko 185]

go558a83nk, even without any firewalling, I have yet to understand how exactly WebRTC/STUN is able to figure out your WAN while a VPN tunnel is established and set as the one and only route - i will do some testing on this tomorrow; in any case, if your firewall:
- denies all incoming traffic
- denies all outgoing traffic except to AirVPN entry server(s)

then there's no way for any application, including browser/WebRTC, to obtain your WAN address. They can phone home but it'll either happen via VPN or it'll fail. AirVPN's Eddie client comes with a similar "network lock" feature.

[go558a83nk 290]

go558a83nk, even without any firewalling, I have yet to understand how exactly WebRTC/STUN is able to figure out your WAN while a VPN tunnel is established and set as the one and only route - i will do some testing on this tomorrow; in any case, if your firewall:

- denies all incoming traffic

- denies all outgoing traffic except to AirVPN entry server(s)

 

then there's no way for any application, including browser/WebRTC, to obtain your WAN address. They can phone home but it'll either happen via VPN or it'll fail. AirVPN's Eddie client comes with a similar "network lock" feature.

 

I run VPN on my router and it was able to see VPN and ISP IP addresses. :-(

[sheivoko 185]

Interesting, this might have made all the difference, as WebRTC/STUN does some NAT magic to map local/WAN ip and port. For testing purposes, can you please try this test while disabling the VPN on your router and connecting to AirVPN directly with your computer? Even if you don't firewall anything, I would be very surprised if your ISP IP was discovered.

[zhang888 1059]

Actually WebRTC/STUN can use the help of ALG and UPnP functions of consumer routers in order to get that information.

Thats why they are generally unsafe, since those features are either on by default, or have a very non-intuitive way to disable them.

 

There are some workarounds for disabling this on Chrome and Firefox, but if you want a more global secure solution just disable those router features.

Also, STUN works on port 3478/udp, you might want to block that with a rule, if all the above fails.

[go558a83nk 290]

OK, did the test with Eddy 2.8 on my win 7 64k machine.

 

with network lock OFF, it could still see my ISP WAN address, and also saw AirVPN address.

 

with network lock ON, it could only see AirVPN address.

 

regarding my router, Asus AC68, UPnP has always been turned off by my choice.  But, not sure what setting would control ALG.  Anybody know?

[go558a83nk 290]

Well, interesting development.  I rebooted my router and Win 7 machine and tested connections to 4 different VPN companies from my router and this test only showed the VPN WAN each time.  So, I don't know what caused the "leak" in previous tests.  I'll have to keep an eye on it.

 

I happen to be testing two other VPN companies right now for a replacement for one I've had for a while. I plan on keeping Air for the foreseeable future.

 

I wanted to test their configs because they use other openvpn options dealing with routes and topology etc that Air doesn't use.

[zhang888 1059]

In any case, STUN, ICE, TURN are all possible due to "leaky" router/NAT settings that allow those ALG protocols.

You can read some technical insights here:

 

 

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

 

This is how you disable it on Asus-C66:

 

http://www.junctionnetworks.com/knowledgebase/onsip/phones-routers-and-devices/router-configuration/asus/asus-rt-ac66u

 

 

 

Asus RT-AC66U devices with their most current firmware enables their SIP ALG by default. THERE IS NO GUI OPTION TO DISABLE IT

So as to add to your knowledge base, I thought I'd share the solution:
To disable the SIP ALG manually, you enable telnet to the device via the WWW interface
Telnet to the device (from a command line enter "telent 192.168.1.1" or the appropriate IP address for the device.)

Issue the following commands:

nvram get nf_sip

(It should return a "1")

nvram set nf_sip=0
nvram commit

Reboot

 

 

There are very tricky ways to disable those ALG handlers, that are mostly used for VOIP. If you use an open-source firmware, it might be your only way to really be sure what's going on.

[go558a83nk 290]

Ah, thanks. I see now I do have that GUI option for disabling SIP passthrough.  I'll do that.  It was set to enabled. 

[zhang888 1059]

Before HTML5 all those potentially dangerous features were at lower risk, because the 3d party would have to run an executable file on your machine to be able to unmask you.

With the new browser "features", such as the Geolocation, RTC, bookmark sharing, peer-assisted networking, and who knows what else, only a properly configured open-source

software at the perimiter, or manual disabling of those easter-eggs can ensure maximum protection.

[packetpuzzler 2]

I appreciate the responses so far. Are the Advanced Members that have been responding part of the AirVPN staff? If not, I would also really like to hear directly from AirVPN about this.

 

Update:

 

FYI: Disabling SIP ALG on my Netgear WINR200V4 router did not fix the problem.

 

However, adding the WebRTC Block Extension from the Chrome Store seems to fix the problem on Chrome (Windows 8.1).

[go558a83nk 290]

I appreciate the responses so far. Are the Advanced Members that have been responding part of the AirVPN staff? If not, I would also really like to hear directly from AirVPN about this.

 

Update:

 

FYI: Disabling SIP ALG on my Netgear WINR200V4 router did not fix the problem.

 

However, adding the WebRTC Block Extension from the Chrome Store seems to fix the problem on Chrome (Windows 8.1).

 

what was your problem?  was your real ISP IP address showing up?  if only the VPN IP address was showing up then there's really no problem.  of course, you can still block it (in Chrome ) or shut it off (Firefox) if you desire.

[mhalen 2]

is there any downsides to setting media.peerconnection.enabled to false? what could potentially stop working?

[OpenSourcerer 939]

is there any downsides to setting media.peerconnection.enabled to false? what could potentially stop working?

 

Your browser cannot start direct audio/video conversations with other clients. Decentralized Skype, so to speak.

[go558a83nk 290]

I see Air now include the WebRTC check on ipleak.net. 

[usr32 2]

Im a little concerned about this. For now I set media.peerconnection.enabled to false but there are some things I don't understand.

 

For example. If I use Cisco VPN from my company STUN doesn't reveal my ISPs IP but when using AirVPN it does. Sure, Network lock prevents it

​but I don't want to use it all the time because it messes with my Firewall. So why is this happening with OpenVPN but not Cisco VPN?

​

​I am connected through a router with all unnecessary services disabled. I use Windows Firewall Control. Is there a way to prevent this globally?

[usr32 2]

So I solved the problem with the additional arguments:

 

route-nopull

redirect-gateway bypass-dhcp

 

This is to ignore the argument def1 that is being pushed by the server to the client that is responsible.

But:

 

dhcp-option DNS x.x.x.x

route x.x.x.x

 

will be ignored. So the DNS of the server will not be used. If you add this argument with a public DNS or 10.4.0.1 it should be fine.

 

I don't know if route is important in this case. I did not experience any differences when adding route 10.4.0.1 or leaving it out.