Jump to content
Not connected, Your IP: 44.200.230.43
go558a83nk

WebRTC used to reveal real IP address

Recommended Posts

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?

Share this post


Link to post

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.


all of my content is released under CC-BY-SA 2.0

Share this post


Link to post

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. :-(

Share this post


Link to post

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.


all of my content is released under CC-BY-SA 2.0

Share this post


Link to post

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.


Occasional moderator, sometimes BOFH. Opinions are my own, except when my wife disagrees.

Share this post


Link to post

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?

Share this post


Link to post

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.

Share this post


Link to post

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.


Occasional moderator, sometimes BOFH. Opinions are my own, except when my wife disagrees.

Share this post


Link to post

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.


Occasional moderator, sometimes BOFH. Opinions are my own, except when my wife disagrees.

Share this post


Link to post

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).

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post

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.


NOT AN AIRVPN TEAM MEMBER. USE TICKETS FOR PROFESSIONAL SUPPORT.

LZ1's New User Guide to AirVPN « Plenty of stuff for advanced users, too!

Want to contact me directly? All relevant methods are on my About me page.

Share this post


Link to post

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?

Share this post


Link to post

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.

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Security Check
    Play CAPTCHA Audio
    Refresh Image

×
×
  • Create New...