Security Alert – Fix Your Browser to Prevent Your Real IP Address From Showing


Recently it has been revealed that there is (and has been) a way to expose your real IP address when using a VPN or other proxy. The method revolves around using the WebRTC (Web Real-Time Communication) API and STUN (Session Traversal Utilities for NAT). Fortunately, there are some simple fixes for this issue.

To test if your browser(s) are unprotected, enable your VPN connection and go here:

Real IP address with STUN

As you can see from the screenshot above, when using a vulnerable Chrome browser, my real IP address was gleaned despite having an active VPN connection. The solutions to fix this problem are detailed below:


*** UPDATE Aug 3, 2015 *** — Google has now released a new extension to block all WebRTC requests.

1) Simply titled “WebRTC Network Limiter,”this plugin will stop normal WebRTC requests along with indirect requests, such as via an iframe.

According to the release notes, this small 7kb addon will do the following:

What it does:
This configures WebRTC to not use certain IP addresses:
  –  IP addresses not visible to the public internet (e.g. addresses like
  –  any public IP addresses associated with network interfaces that are not used for web traffic (e.g. an ISP-provided address, when browsing through a VPN)
Once the extension is installed, WebRTC will only use public IP addresses associated with the interface used for web traffic, typically the same addresses that are already provided to sites in browser HTTP requests.

You can (and probably should) download and install the WebRTC Network Limiter addon for Chrome [here].

***UPDATE***: As this issue has gained a lot of attention, the WebRTC testing page was recently updated to test WebRTC requests using an iframe, and it appears that the WebRTC-Block plugin for Chrome does NOT BLOCK all types of WebRTC requests.

We have reached out to the creator(s) of WebRTC Block to find out if they are able to update their extension to stop all forms of WebRTC requests. We will keep you posted on any updates we get from them, and if any new extensions or solutions arise.

At this time there are limited options for Chrome users to eliminate the issue completely. Using FireFox with the fix described below, or an alternative browser that is not affected or does not implement WebRTC is currently the safest option.

Chrome users can take the following steps to help reduce the risk of WebRTC but none of these options currently eliminate the issue entirely.

1) The WebRTC Block extension still helps. It properly blocks standard WebRTC requests that are not loaded via an iFrame.

2) Use a script blocking extension such as ScriptBlock or ScriptSafe (listed below) which blocks all scripts until you trust the domain the scripts are loaded from. These extensions do not block WebRTC specifically but they do block JavaScript which is required for WebRTC to work. Note that once you trust a domain, if a script on that domain triggers a WebRTC request you may be still vulnerable.

Pairing Option #1 with a script blocking extension is the best option if you are unable to use an alternative browser.

ScriptBlock – This is the smaller sized plugin of the two, sized at 148k. An example interface is shown below:


ScriptSafe – This plugin is slightly larger at 248k, and also works very well to block website scripts. The interface example is shown below:


Once installed, you can test if it works by reloading the page [here]. If you do not see any IP addresses showing, then you are protected (see screenshot below).


FireFox has more options to use for blocking scripts, like NoScript, but the easiest way to block WebRTC requests is the following:

1. In a new or existing tab, type the following: “about:config”

2. Click the “I’ll be careful, I promise!” button.

3. In the Search box, type “media.peerconnection.enabled” (see below image)

peerconnection enabled

4. Double-click the “media.peerconnection.enabled” line, and it will automatically change the value to False (see below)

peerconnection disabled

5. That’s it!



Now that you have configured your browser(s) to not allow WebRTC requests, confirm that you are no longer leaking your real IP address.

1. Turn on your VPN connection if it is not on.

2. Visit

3. If the page does not show any IP addresses at all, then you have correctly configured your browsers. The page should look like this:

IP address webrtc stun fixedAnd that’s it! You can count on IronSocket to continue proactively informing and helping protect you from new privacy threats as they emerge. Feel free to leave any comments below!

Update: Please follow the same steps above for all of your browser profiles (if applicable), to make sure this vulnerability is completely fixed on your computer.

Update2: Thanks to our subscribers and commenters for bringing up the new issue with WebRTC being accessible through an iframe.

About Dan Johnson

Dan has been involved with computers in the early 1990s with a 2400 baud dialup modem. Since then, he has been working on various internet projects for over a decade and makes a conscience effort to inform others about staying safe on the internet. Currently he works with IronSocket and some other online side projects, when not hiking through the pine forests around his house.

  • Jean-Mouloud

    I see it as a feature actually to voluntarily reveal the real ip to some websites.
    Would be good to be able to set a whitelist of websites to allow webRTC requests.

  • Matthew Niederberger

    Thanks for the tip. Installed the Chrome plugin and it worked like a charm.

  • Dave

    Thanks Dan – but what functionality could we potentially lose with it disabled?

    • IronSocket

      That’s a good question. To my knowledge, any website that uses the technology to determine your IP address / geo-location may be affected if they utilize WebRTC/STUN to get your IP address as opposed to your normal outward facing IP address (like your VPN connection.) I personally really do not see the downside to blocking WebRTC.

  • BRossow

    The Chrome extension appears to be working on some test sites, but still reveals my real internal and external IPs with ease.

    • IronSocket

      Thanks for that comment, and you’re correct, WebRTC could still be accessed using an iframe and the original tool did not test it using that method. The blog post has been updated accordingly =)

  • Jayne Vanderlay

    Chrome for Ios does not appear to have this problem with OpenVPN.