GUIDE

A Complete Guide to IP Leaks

Contents

DNS Leaks

The WebRTC “bug”
VPN dropouts (and kill switches)

Using Firewall rules (a global fix)

Introduction

One of the primary reasons to use a VPN is to hide your true IP address. When using a VPN, all your internet traffic is encrypted and sent to a VPN server run by your VPN provider, before exiting to the internet.

This means that outside observers can only see the IP address of the VPN server, and not your true IP address. The only way for them to discover your true IP address, therefore, is to convince your VPN provider to hand it over to them (and good providers use robust measures, such as using shared IPs and keeping no logs, to make this as difficult as possible.)

At least this is the theory…

Unfortunately, and for various reasons discussed below, it is sometimes possible for websites to detect your true IP address, even when using a VPN.

I have discussed all the issues listed here at length before on BestVPN (and will link to relevant articles where appropriate), but it is time to bring together all known causes that may answer the questions: Why is my IP leaking even though I am connected to a VPN? And how do I fix it?

To determine if you are suffering an IP leak, visit ipleak.net. If you are connected to a VPN and you can see your true IP address (or even just your ISP’s name) anywhere on this page then you have an IP leak.  Note that ipleak.net does not detect IPv6 leaks, so to test for these you should visit test-ipv6.com.

Update: I have discovered another great tool for testing for IP leaks, which can be found at doileak.com. Note that it includes tests that do not really count as “IP leaks”, but which are great for improving your overall browser security.

DNS leaks

The Dynamic Name System (DNS) is used to translate the easy-to-understand and remember web addresses that we are familiar with, to their “true” numerical IP addresses: for example translating the domain name www.bestvpn.com to its IP address of 216.172.189.144.

Every internet connected device, and every internet connection, has a unique IP address that is used to identify it (although these can change), including your computer and smart phone, etc. We call this your “real IP” (as opposed to the “fake IP” provided by your VPN server.)

This DNS translation process is usually performed by your ISP, but when using a VPN all DNS requests should be sent through your encrypted VPN tunnel, to be handled by your VPN provider instead.

Using the right scripts, a website can determine which server resolved a DNS request directed to it. This will not allow it to pinpoint your exact real IP address, but will foil attempts to geo-spoof your location, and allows police etc. to demand that your ISP hand over your real IP address (ISPs keep records of these things, while  good VPN providers do not.)

Most VPN providers run their own dedicated DNS servers in order to perform this DNS translation task themselves, but some make use of public DNS services such as Google DNS instead. Although not ideal, this is not the privacy nightmare it might at first seem, as the DNS requests appear to come from your VPN provider, not your real IP.

Unfortunately, internet traffic does not always get sent through the VPN tunnel as it is supposed to, and is instead resolved by your ISP…

IPv4 DNS leaks

Until recently, the entire internet used the Internet Protocol version 4 (IPv4) standard to define IP addresses. Unfortunately, thanks to the unprecedented rise in internet use over the last few years, IPv4 addresses are running out (in fact technically speaking they have already done so), as IPv4 only supports a maximum 32-bit internet address. This translates to 2^32 IP addresses available for assignment (about 4.29 billion total). For now, however, the vast majority of internet addresses still use the IPv4 standard.

When using a VPN, your Operation System (OS) can sometimes get confused, sending IPv4 requests through to the DNS server specified in its default settings (usually run by your ISP), instead of through the VPN tunnel (as it’s supposed to.) This can occur with any OS, but Windows is notably guilty in this respect.

Fixes

  1. Use a VPN client with built-in “DNS leak protection”. This is basically just a firewall that ensures no internet traffic can leave your computer unless it goes through the VPN. Many good providers offer this feature in their custom VPN clients (sometimes called something else), but it is not available in the generic open source OpenVPN client.
  2. Use VPNCheck Pro (Windows). Although primarily an “internet kill switch”, the Pro version of this tool also includes a DNS leak fix.

IPv6 DNS leaks

While various mitigating strategies have been deployed to extend the shelf-life of IPv4, the real solution comes in the form of a new standard – IPv6. This utilizes 128-bit web addresses, thus expanding the maximum available number web addresses to 2^128, which should keep us supplied with IP addresses for the foreseeable future.

Adoption of IPv6, however, has been slow – mainly due to upgrade costs, backward capability concerns, and sheer laziness. Consequently, although all modern Operating Systems support IPv6, the vast majority of websites do not yet bother.

This has led websites that support IPv6 to adopt to a dual-tiered approach. When connected to from an address that only supports IPv4, they will serve up an IPv4 address, but when connected from an address that supports IPv6, they will serve up an IPv6 address.

Unfortunately, most VPN software fails to direct IPv6 traffic through the VPN tunnel, so when you connect to an IPv6 enabled website, your browser will make an IPv6 DNS request outside the VPN, which is therefore handled by your ISP.

VPN providers that offer “DNS leak protection” in their clients’ usually side-step the problem by simply disabling IPv6 in the OS. This is effective at preventing IPv6 leaks, but is hardly forward looking, and we would like to see providers offer true IPv6 support in their products (Mullvad is the only provider that claims to properly route IPv6 calls. We have not tested this yet, but if true then Mullvad is very much to be commended.).

iOS is supposedly (.pdf) immune to IPv6 leakage.

Glass Mirror 2

As noted above, the best tool for detecting IPv6 leaks is test-ipv6.com (they are not detected by ipleak.net.)

This result shows that IPv6 has been disabled, so IPv6 leaks are not possible. In a perfect world it should be possible to enable IPv6, while only detecting your VPN provider’s IP address (you can check who an address belongs to by entering “whois [ip address] into a search engine.)

Fixes

  1. Use a VPN client with built-in “DNS leak protection”. This disables IPv6.
  2. Disable IPv6 manually. Instructions for doing so are available for Windows, OSX Mac, and Linux. The more paranoid out there may prefer to do this even if using a VPN client with “DNS leak protection”.
  3. The OpenVPN for Android app has the option to properly route all IPv6 traffic over the VPN. To ensure this is enabled:

OVPN Android 1

Go to the specific server connection settings, then navigate to Routing

OVPN Android 2

Ensure that IPv6 -> “Use default Route” is checked. Note also the IPv4 leak protection

Smart Multi-Homed Name Resolution (mainly a Windows 10 problem)

A new “feature” in Windows 10 means that DNS requests are directed not just through your VPN tunnel, but also through your ISP and local network interface. This is because by default Windows 10 attempts to improve web performance by sending DNS requests in parallel to all available resources at once, and (at least in theory) using the fastest one.

Under Windows 7 all DNS requests were made in simple order of DNS server preference, but this changed in Windows 8 when Microsoft added “‘Smart Multi-Homed Name Resolution” by default. This sends out DNS requests to all available interfaces, but only uses non-preferred servers if the main DNS server failed to respond.

This makes Windows 8.x systems somewhat liable to DNS leaks, but Windows 10 makes the situation much worse as it simply chooses whichever DNS request responds quickest. In addition to being major security risk, there are also reports of Windows 10 users suffering slow page loading and timeouts due to this issue

This problem has led the United States Computer Readiness Team (US-CERT), an official department of the US Department of Homeland Security, to issue an alert.

Fixes

  1. There is now an OpenVPN plugin to fix this problem. It should work with all versions of Windows, and should also work with most custom OpenVPN clients that use a standard .ovpn configuration file (i.e. most of them.)
  2. Anecdotally, I have never suffered DNS leaks in Windows 8.1 due to this issue, but nevertheless advise all Windows 8, Windows 8.1, and especially Windows 10 users to disable Smart Multi-Homed Name Resolution if possible*. Avast has published some great instructions on how to do this.

Disable Smart Multi-Homed Name Resolution

*Unfortunately, the ‘Turn off smart multi-homed name resolution’ option is not available in Windows Home Editions. Luckily, the OpenVPN plugin mentioned above should fix the problem for most users’ anyway. Whew!

The WebRTC “bug”

Web Real-Time Communication (WebRTC) is a potentially useful standard that allows browsers to incorporate features such as voice calling, video chat, and P2P file sharing directly into your browser.

A good example of this is the new Firefox Hello video and chat client that lets you talk securely to anyone else using an up-to-date Firefox, Chrome, or Opera browser, without the need to download any add-on, or configure any new settings.

Unfortunately for VPN users, WebRTC allows a website (or other WebRTC service) to directly detect your host machine’s true IP address, regardless of whether you are using a proxy server or VPN.

Given that WebRTC is potentially useful, it is something of a shame that the only way to prevent it from leaking your true IP address is to disable WebRTC in your bowser completely (although the Statutory add-on does allow you whitelist individual websites.)

The WebRTC issue only affects the Firefox, Chrome, and Opera browsers (not Internet Explorer or Safari etc., as these do not include WebRTC functionality.) Update: newer versions of the stock Android browser appear to implement WebRTC, and so should be avoided.

Fixes (Firefox)

1. Type ‘about:config’ into the URL bar to enter Firefox’s advanced settings, and then change the ‘media.peerconnection.enabled’ value to false.

WebRTC firefox fix

2. Various browser plugins can disable WebRTC, including Disable WebRTCuBlock Origin, NoScript, and Statutory.

For more information on the WebRTC “bug”, full instructions on how to disable WebRTC in Firefox, plus a more detailed look at the various browser plug-in solutions available (various browsers,) please check out my article on The WebRTC VPN “Bug” and How to Fix It.

VPN dropouts (or why you need a “kill switch”)

Sometimes VPN connections fail. With a good VPN provider this should not happen very often, but it occasionally happens even to the best. If your computer continues to remain connected to the internet while after this happens, then your real IP will be exposed.

Although not technically an “IP leak”, as the problem occurs exactly because you don’t have a VPN connection, the effect is the same – you think that you are protected by VPN, when in fact the whole world can see your IP address.

This is particularly a problem for P2P downloaders who leave BitTorrent clients running while they are away from their computers (often for long periods of time). If the VPN connection drops, their true IP is therefore exposed to any copyright enforcers tracking a torrent they are downloading.

Fixes

  1. Use a “VPN kill switch” (also called, somewhat more accurately, an “internet kill switch”.) These either monitor your internet connection and shut it down when they detect a VPN dropout, or use firewall rules to prevent any internet traffic leaving your computer outside of your VPN connection.

Many providers’ custom VPN clients include a built-in kill switch (sometimes called something else, such as “network lock”,) or you can use third-party solutions such as VPNetMon, VPN Check, or VPN Watcher. The Viscosity OpenVPN client even supports per app kill switches (you can specify which individual apps can only access the internet using VPN.)

Interestingly, the OpenVPN for Android app can be setup to work as a kill switch. The app will automatically attempt to reconnect to your VPN in the event of a VPN dropout (which is good, as this will occur whenever you move between WiFi routers, or WiFi and a mobile connection!).

To configure the app as a kill switch, edit the specific VPN connection (see IPv6 above), and navigate to “Advanced”.

OVPN Android 3

Check “Persistent Tun” and set “Connection retries” to Unlimited. Ta-da! You now have an OpenVPN kill switch for Android.

  1. Create your own kill switch using Firewall rules (see below.)
  2. Configure the Vuze BitTorrent client to only download over VPN. This is not a true solution to the problem, but can be very effective for those whose primary concern is VPN dropouts while downloading via P2P. Detailed instructions how to setup Vuze to do this are available here (where I also discuss how to configure VPNetMon and VPN Check as kill switches.)

Using Firewall Rules ( a global fix)

A unified solution to all of the above issues is to use a firewall, configuring it so that only connections to the VPN server are permitted through the firewall. Details differ by OS and firewall program, but the basic principles are:

1. Add a rule that blocks all outgoing and incoming traffic on your Local Ethernet Device.
2. Add an exception for your favorite DNS Server (to resolve the hostname of your VPN provider)
3. Add an exception for your VPN provider’s IP addresses
4. Add an Rule for your tun/tap or any other VPN Device to allow all outgoing Traffic for the VPN Tunnel.*

I have a detailed guide for doing this using Comodo Firewall (Windows), and guides are also available using the Windows 7 (not 8+) built-in firewall, and Little Snitch (Mac OSX). Those familiar with iptables should have no problem doing something similar in OSX and Linux. * My thanks to reader x22 for concisely formulating these principles.

Conclusion

If using a good VPN client that features “DNS leak protection” and a kill switch, you should have little to worry about when it comes to accidentally exposing your real IP address when using VPN (although Windows 10 users should watch out for the Smart Multi-Homed Name Resolution issue.)

OpenVPN for Android users should be particularly chuffed that DNS leak protection and kill switch functionality are built into the generic OpenVPN app (just make sure that they are enabled.)

If your VPN software does not include these features, never fear, as there are plenty of third party solutions to fill the gaps.

It is always a good idea, however, to check  ipleak.net, test-ipv6.com , and doileak.com periodically, just to make sure that nothing is amiss.

 


Douglas Crawford I am a freelance writer, technology enthusiast, and lover of life who enjoys spinning words and sharing knowledge for a living. Find me on Google+

Related Coverage


18 responses to “A Complete Guide to IP Leaks

  1. Nice post.

    Here’s some info for users of various GNU Linux distributions. dnsmasq will cause your system to leak DNS info.

    I would like to bring attention to caching dns clients. *nix systems (Gnu Linux distributions, FreeBSD, etc.) have traditionally run a piece of “system” software called BIND which stands for the Berkeley Internet Name Daemon. When running this software is responsible for handling any DNS requests made by or to the system it is on. There are other systems which “compete” with BIND. One which comes to mind is tinyDNS. This is still a full featured DNS handler.

    I have very successfully and happily used BIND on my desktop computer at home using an IP address dynamically assigned by my ISP. However, most people including myself would find these examples of DNS software unsuitable for running in a “road warrior” configuration on one’s laptop. But DNS lookups still need to be handled. This brings the program known as dnsmasq into the show. dnsmasq is a “smaller” system than BIND and other general purpose DNS management software. Its description on the Gnu Linux distribution I am running (Kubuntu) is “dnsmasq – A lightweight DHCP and caching DNS server. dnsmasq is a lightweight DNS, TFTP, PXE, router advertisement and DHCP server. It is intended to provide coupled DNS and DHCP service to a LAN.”

    Until I disabled dnsmasq my system running OpenVPN leaked my DNS info. It may be possible to configure dnsmasq to not leak this info but I’m not sure and I think it would be difficult and inflexible in the “road warrior” scenario of frequently changing networks and IP addresses. The easiest and most consistent fix is to disable it. I accomplished this by commenting out its line in the configuration file:

    /etc/NetworkManager/NetworkManager.conf
    #dns=dnsmasq

    The ‘#’ at the beginning of the line makes the line a comment and causes it to be ignored by NetworkManager. You could just delete the line but in my experience it is better to “comment-it-out” just in case you decide to do things differently in the future. If you delete it you’d have to remember it was there, what it was called, etc. Now you can just uncomment it.

    Now my VPN provider’s DNS servers are completely responsible for handling all DNS requests from my computer.

    Hope someone finds this information useful.

    1. Hi Duane,

      Thanks! I have not encountered this problem myself, but I’ sure this post will be useful to others.

  2. Hello,

    I’m still confused wether my systems are leaking DNS requests or not.
    I have two devices using OpenVPN, an Android Phone and Laptop with Debian OS.
    In both systems the IPs 208.67.222.222, 208.67.220.220, 208.67.222.220 and 208.67.220.222 are used for DNS (OpenDNS). They are not only written in the VPN settings, but also in the general network settings, so even when disabling VPN, all requests should go to the OpenDNS server instead of my ISP’s.

    The problem is now that I don’t know if the requests are tunneld through the VPN connection.
    I used doileak.com to analyse the situation and I get this report:

    “We did get DNS requests from the following IPs:
    208.69.32.13: OpenDNS, LLC (36692), United States (NA) (Leak?)
    208.69.32.11: OpenDNS, LLC (36692), United States (NA) (Leak?)
    208.69.32.22: OpenDNS, LLC (36692), United States (NA) (Leak?)
    We received DNS requests from you via a DNS server from another AS (routable network) than your HTTP request. This could mean that your DNS requests are leaking.”

    So I don’t know if this is okay or not, maybe someone can help me with this problem?

    Thank you 🙂

    1. Hi Ruamzuzla,

      If all DNS requests are being handled by OpenDNS, then they are not being handled by your VPN provider. By definition this means that you have a DNS leak. Does your VPN provider’s software offer a DNS leak protection / Network Lock feature? If so, then turning it on should ensure that all DNS requests are handled by your VPN provider (as this feature is basically a firewall that prevents any internet communication outside the VPN connection). Note that is your VPN provider handles the DNS requests (as it should do), then you will not be using the OpenDNS servers.

      1. Hello,
        thank you for you fast answer.

        So the problem is that my VPN service (PureVPN) only let you use their DNS server, when you allow your public IP in their webinterface. But my public IP is changing every few days, so this is not a solution.
        The other option would be to use their software, but there is only a client for Windows and I need something for Debian and Android.

        But I just found my situation described in this guide under point 3 (using a public DNS). So I just don’t get, why this is still a problem and if a DNS provider can see my IP or not (that would be the leakage, wouldn’t it?).
        https://www.bestvpn.com/blog/5184/4-ways-to-prevent-a-dns-leak-when-using-vpn/

        Furthermore I’m used to Wireshark.
        So I started protocolling all outgoing connections, and when analysing all endpoints I can see, that every request, even the DNS requests are send through the tunnel. There is no other endpoint than the VPN server I am connected to.
        When I understand that properly, then any DNS server can not see my IP adress, only the one from my VPN (DNS request of my computer -> VPN -> DNS server and the way back to my computer).

        How is it possible, that the request can leak out of the tunnel, even when I would use my ISP’s DNS? I think I understand the DNS problem in theorie, but the technical background is not explained anywhere.

        Hope you can clarify this situation to me 🙂

        1. Hi Ruamzuzla,

          So in order to route your DNS requests to its servers when you are not using its custom software, you must tell PureVPN your local IP address using its webinterface. All well and good, except that because your ISP assigns you a dynamic IP, your IP changes every few days?

          I think you are getting confused over Point 3 in 4 ways to prevent a DNS leak when using VPN. This sets your PC to always use a set DNS server. But if you tell PureVPN your local IP address using its webinterface then it will simply reroute all DNS requests from that address to its own DNS servers.

          You can either:

          a) Not tell PureVPN your IP address. In this case all DNS requests will be handled by the DNS server that you set in your OS (e.g. an OpenDNS). Or…

          b) You can use a managed IP service. These monitor your dynamic IP addresses and link them to a static IP. You can give the static IP to PureVPN. no-ip has free plan that offers this.

  3. Just a heads up. “The Dynamic Name System (DNS) is used to translate” is incorrect. I think you’re confusing your acronyms because DNS stands for Domain Name System and you have it sounding like DHCP – Dynamic Host Configuration Protocol.
    See from the people who’s equipment runs most of the Internets infrastructure.
    http://www.cisco.com/c/en/us/about/security-center/dns-best-practices.html
    or check out the wiki
    https://en.wikipedia.org/wiki/Domain_Name_System

    1. Hi dev/null,

      “DNS is a globally distributed, scalable, hierarchical, and dynamic database that provides a mapping between hostnames, IP addresses (both IPv4 and IPv6), text records, mail exchange information (MX records), name server information (NS records), and security key information defined in Resource Records (RRs).” It is basically an address book that cross-references domain names (www.blahblah.com) with numerical IP addresses. I think the way I have described it is perfectly clear and accurate.

      What I am not talking about is DHCP, in which IP addresses are dynamically allocated to users.

  4. The site has a wealth of knowledge shared in a understandable way. This page in particular was very useful, thank you. I’ll be back and hopefully so will some others who I’ll refer this site to.

  5. Thank you. After wasting hours collecting all the above informations in little pieces I finally found this great article.

Leave a Reply

Your email address will not be published. Required fields are marked *