Easy, quick, DNS and IPv6 Leak testing via command prompt/line method - No browser or website needed

edited June 2017 in General VPN Support Posts: 173
Did you know that Windows and other commonly used operating systems (e.g. Linux, MacOS) already have a built in DNS and IPv6 leak test ability? Didn't know that huh, well, you did if you've ever heard of the command prompt but maybe you didn't know you knew it. For DNS leak testing the methods are outlined in this post for command prompt and PowerShell with some PowerShell variations in the fourth post in this thread. IPv6 leak testing is covered in the fifth post in this thread for both command prompt and PowerShell. The command prompt methods can also be used in Linux and MacOS, just make the proper adjustment for your OS. Beginning in the seventh post in this thread are versions or a small app based upon the PowerShell methods for Windows 10 if you prefer an app based method for Windows 10.      

When it comes to DNS leak tests commonly used test sites portray two basic things; First, you need many recursions across their many virtual test servers in their test domain to determine if you have a DNS leak or not. Second, you need to know all of the DNS servers if its more than one that may show up in their test to determine if you have a leak.

Those two things are not really true.  

To conduct a DNS leak test you need one properly configured server that will only return the querying DNS IP address and only one leaking DNS IP showing up to determine you have a DNS leak, or, only your pubic VPN IP being returned which means you do not have a DNS leak - its as simple as that. A DNS leak test is something you can do yourself in less than 10 seconds from your own computer using what is already present in the operating system. 

There are servers on the internet set up to return only the querying DNS IP address. The servers listed below will return the querying DNS IP all the time and are not prone to the failures/errors/time delays generated by the more commonly used DNS leak test site virtual server arrangement and process. Their use, described below, is fast and painless by using 'ping', 'nslookup', 'dig' or PowerShell. All you need is the ability to ping the servers with a single ping, or use 'nslookup', 'dig' or PowerShell methods, knowing your VPN Public IP address, and being able to see the returned results. In the below I use Windows, make the necessary adjustments for your particular OS if not Windows. If you need your Public IP address on VPN see the section at the bottom of this post called 'How to get your Public IP address on or off VPN:'

A few of the test servers are:

whoami.akamai.net
resolver.dnscrypt.org
whoami.fluffcomputing.com
whoami.ultradns.net

'Ping' method for DNS leak testing:

1. Open up a Windows command prompt and enter > ping whoami.akamai.net -n 1 < the "-n 1" tells ping to send only one ping. For the Linux based OS and MacOS use '-c 1' in place of the below Windows example '-n 1', MacOS use 'Terminal'.

2. Hit the Enter key.

3. To determine if you have a DNS leak or not look at the IP's returned in the ping results; To experiment, try this on and off VPN to get an idea of what is returned. Off VPN (e.g. on your ISP connection) it will return a DNS server address in your ISP DNS path chain and not your ISP public IP, if using other than your ISP DNS it will return a DNS server relative to that DNS path chain. On VPN it will return your VPN Public IP if you do not have a leak else the IP address of your DNS leak is returned if you do have a leak.

Repeat steps 1 - 3 with the other servers if you wish but one server will be enough. Here are the command lines:

ping whoami.akamai.net -n 1
ping resolver.dnscrypt.org -n 1
ping whoami.fluffcomputing.com -n 1
ping whoami.ultradns.net -n 1

A pic to illustrate [the IP's in red rectangles matches the known VPN Public IP, no DNS leak]:


If you need the ping response to be a less verbose (in Windows) you can clean it up using '| find "Reply' as shown below:

ping <server here> -n 1 | find "Reply" - for example: ping whoami.akamai.net -n 1 | find "Reply"

which gives you a response return that looks like, for example, this:


If you prefer to make multiple passes, although not needed,  for a test server the change '1' in the '-n 1' to the number of passes. For example, if we wanted to make six passes the line would look like this:

ping <server here> -n 6 | find "Reply" - for example: ping whoami.akamai.net -n 6 | find "Reply"
 
There ya go, simple and easy DNS leak testing in less than 10 seconds. Less time than it takes to open up a browser, navigate to a test site, click on buttons, wait for the test to finish and quit hogging the browser and your time or having to deal with slow, or not working properly, test sites. Remember - you only need to use one of the test servers for a DNS leak test but you can use all four if you wish.

What can be simpler than this. If you have a leak and try more than one of the test servers each one may return a different leaked DNS IP because there are multiple DNS servers in the path so you might see different leaking DNS IP's for each if there is a leak. Here's the thing though, all you need to know is that one DNS IP is leaking, so fix the leak condition issue and no more leaks for any of them.

To illustrate these servers detecting a DNS leak I intentionally created a DNS leak condition using OpenDNS DNS servers (so my ISP DNS is not exposed in this). The test for this DNS leak is depicted in the pic below which has two views. The top view is PowerShell in which you can see the VPN Public IP in the green rectangle and the leaked DNS IP in the red rectangles. The bottom view is the Windows command prompt using the ping method in which you can see the leaked DNS IP's also. Notice that IP's 204.194.238.21 & 204.194.238.19 are being leaked, they resolve to the 'm11.dfw.opendns.com' and 'm9.dfw.opendns.com servers in the OpenDNS DNS server path chain. I only showed these two for illustration to keep the pic size smaller. There were several actually leaked and the test servers detected all of them using the methods outlined in this post. You can see below the returned IP's from the methods presented here did not match the VPN Public IP address and thus a DNS leak detected. If there was no DNS leak the IP's in the red rectangles would have matched the VPN Public IP address.


'nslookup' method for DNS leak testing:

Using nslookup is simple and easy also, but the return looks a little different from the 'ping' method. The 'nslookup' method is also applicable to the MacOS and Linux based OS's. For Linux use 'dig', for MacOS use  'nslookup', in Terminal. In the pic below is illustrated use of the nslookup method. The 'find "Address" ' part (in Windows) makes the response less verbose, try without that part to see the difference:

Referring to the above pic; The top 'Address' line is the DNS server configured for the TAP adapter, if you have DNS Leak Protection enabled in the PIA client this should be a PIA DNS server. If you manually set the DNS in the TAP adapter properties to something else the IP of that DNS server will appear here. This is the DNS server by which your are querying through nslookup. If something other than the PIA DNS Leak protection enabled DNS appears here or a server you did not manually set appears then you need to address that issue because something is wrong.  

The focus for the purpose of DNS leak testing is the bottom 'Address' line. If you have a DNS leak the IP address here will not be your VPN Public IP address and will be the leaked DNS IP. If you do not have a DNS leak your VPN Public IP will appear in the bottom 'Address' line. The command lines you need are:

nslookup -q=A whoami.akamai.net | find "Address"
nslookup -q=A resolver.dnscrypt.org | find "Address"
nslookup -q=A whoami.fluffcomputing.com | find "Address"
nslookup -q=A whoami.ultradns.net | find "Address"

(note for the 'nslookup' method - the | find "Address" part is optional, it reduces the displayed response to that in the pic above.)

PowerShell methods for DNS leak testing:

The 'ping', 'nslookup', and 'dig' methods are for everyone, use the method that best suits you and your OS. However, PowerShell folks tend to use PowerShell in place of the traditional command prompt method for many things. PowerShell is primarily available for Windows 7 and above. Its natively integrated into the Windows 10 OS. PowerShell is now open source with a version for Linux I think, not sure about MacOS at this time. The below is based upon PowerShell (version 5.x) natively available in Windows 10.

Four methods for PowerShell users, basically copy-n-paste script or application ready:

Powershell cmdlets 'Test-Connection' method:

(Test-Connection whoami.akamai.net -Count 1).IPv4Address.IPAddressToString
(Test-Connection resolver.dnscrypt.org -Count 1).IPv4Address.IPAddressToString
(Test-Connection whoami.fluffcomputing.com -Count 1).IPv4Address.IPAddressToString
(Test-Connection whoami.ultradns.net -Count 1).IPv4Address.IPAddressToString

PowerShell .Net 'GetHostAddresses' method:

[System.Net.Dns]::GetHostAddresses('whoami.akamai.net')[0].IPAddressToString
[System.Net.Dns]::GetHostAddresses('resolver.dnscrypt.org')[0].IPAddressToString
[System.Net.Dns]::GetHostAddresses('whoami.fluffcomputing.com')[0].IPAddressToString
[System.Net.Dns]::GetHostAddresses('whoami.ultradns.net')[0].IPAddressToString

PowerShell cmdlets 'Resolve-DnsName' method:

(Resolve-DnsName whoami.fluffcomputing.com -Type A).IPAddress
(Resolve-DnsName resolver.dnscrypt.org -Type A).IPAddress
(Resolve-DnsName whoami.ultradns.net -Type A).IPAddress
(Resolve-DnsName whoami.akamai.net -Type A).IPAddress

The 'Resolve-DnsName' method, if a server is too slow for you or is down add the '-QuickTimeout' to lessen the wait timeout:

(Resolve-DnsName <test server name here> -QuickTimeout -Type A).IPAddress

(note: For the Resolve-DnsName method you will need to specify record type '-Type A' or it will be very slow.)

PowerShell 'New-Object' method using .Net 'Ping':

$ping = New-Object System.Net.NetworkInformation.Ping; $ping.Send('whoami.akamai.net', 5000) | Select Address

$ping = New-Object System.Net.NetworkInformation.Ping; $ping.Send(
'whoami.ultradns.net', 5000) | Select Address
$ping = New-Object System.Net.NetworkInformation.Ping; $ping.Send(
'resolver.dnscrypt.org' , 5000) | Select Address
$ping = New-Object System.Net.NetworkInformation.Ping; $ping.Send(
'whoami.fluffcomputing.com', 5000) | Select Address

(note: The 5000 is a timeout value in ms, if you think you need a time out value then set it here - 1000ms = 1 second. Its optional.)

The Test-Connection and New-Object ping methods above are the PowerShell equivalent of the ping method in a Windows command prompt. The Resolve-DnsName method is the PowerShell equivalent of the nslookup or dig methods. The .Net GetHostAddresses() method may not have been an obvious choice for some but it works because the only IP that can be returned with these test servers is the querying DNS IP and the method serves to verify that as well. 

The pic below - using the PowerShell methods, in the red rectangles is the VPN Public IP being returned meaning no DNS leak:


Also for the PowerShell users - if you need your VPN Public IPv4 address here are a few ways...

Invoke-RestMethod -Uri https://api.ipify.org?format=json -TimeoutSec 20 | Select -exp ip
Invoke-RestMethod http://ipinfo.io/json -TimeoutSec 20 | Select -exp ip
(Invoke-WebRequest http://myip.dnsomatic.com -TimeoutSec 20).Content
(Invoke-WebRequest http://ipv4.myip.dk/api/info/IPv4Address -TimeoutSec 20).Content
(Invoke-WebRequest http://ipv4.whatismyip.akamai.com -TimeoutSec 20).Content
Invoke-RestMethod https://ipv4.ipleak.net/json -TimeoutSec 20 | Select -exp ip

(note: The '-TimeoutSec 20' was used for experimental purposes, left it in to show where it goes if you need it - a timeout is optional.)

Get your Public IP address on or off VPN:

See above where I gave the PowerShell lines for getting the (on or off VPN) Public IP address. Most PowerShell dedicated folks might do this with PowerShell so there are the lines, however, those links posted above in the lines are live on this page. So for everyone all ya gotta do is click them and get your public IPv4 address in your browser. A few of them also give geo-Location info for the IP address. The IP and/or geo-location information returned is in plain text, no graphics or flash or java or other web page things you may be accustomed to seeing. In addition there are methods to get your public IP via command prompt as well. 

If ya really can't live without graphics, ads, tracking, being connected to other domains unknown to you in the background, with a web page and all the other stuff that comes with it; You can get your IP and geo-location info here at the PIA web site > Whats My IP  > or many other places on the internet. You can also get your Public IP IPv4 Address with nslookup or PowerShell cmdlet 'Resolve-DnsName':

With 'Resolve-DnsName' in PowerShell :

(Resolve-DnsName o-o.myaddr.l.google.com -QuickTimeout -Type txt).Strings

With 'nslookup' in command prompt:

nslookup.exe -q=txt o-o.myaddr.l.google.com

The results of the 'nslookup' and
'Resolve-DnsName' methods for getting IPv4 Address

Also for PowerShell users you can use the 'Invoke-WebRequest' cmdlet or its aliases 'curl' or 'wget' to get your public IP address:

(Invoke-WebRequest whatismyip.akamai.com).Content
(curl whatismyip.akamai.com).Content
(wget whatismyip.akamai.com).Content
 

Although not relative to this because PIA is IPv4 only at this point, but a few ways to get your Public IPv6 address with PowerShell if you need it...

(Invoke-WebRequest ipv6.whatismyip.akamai.com -TimeoutSec 20).Content
Invoke-RestMethod v6.ipv6-test.com/api/myip.php?json -TimeoutSec 20 | Select -exp address



Note: The four test servers presented were given because they have known tested and confirmed reliability and standards compliance factors and operate in a continuously maintained environment to ensure continuation and stability of those factors. Although there are some others like this function wise (not that many actually, most are private so not publicly accessible) whats needed for this purpose is that "reliability and compliance" factor which is not found in the others even if they may be usable at times.


Post edited by bgxsec on

Comments

  • Posts: 86
    Thanks for the info.

    FYI for MacOS users.  The "-n" is not valid, and "-c" is the equivalent command.

    Terminal prompt >   ping whoami.akamai.net -c 1


  • edited May 2017 Posts: 173
    (removed - never mind, see p6014037 posted for the MacOs, added to the original post)
    Post edited by bgxsec on
  • edited May 2017 Posts: 173
    In reference to the PowerShell methods for DNS leak testing in the first post in this thread, there are a couple of variations you can use for the 'Resolve-DnsName' and 'Test-Connection' methods already outlined. These two variations are my favorites to use for DNS leak testing where a 'list' of the servers gets piped to the cmdlet;

    ('<serv1>', '<serv2>', '<serv3>', '<serv4>' | % {Test-Connection $_ -Count 1}).IPv4Address.IPAddressToString
    ('<serv1>', '<serv2>', '<serv3>', '<serv4>' | % {Resolve-DnsName $_ -QuickTimeout -Type A}).IPAddress

    where <serv1>, <serv2>. <serv3>. <serv4> are replaced by one each of the four test servers from the first post in this thread like this:

    ('whoami.fluffcomputing.com', 'resolver.dnscrypt.org', 'whoami.ultradns.net', 'whoami.akamai.net' | ... the rest of the line..

    Don't remove the single quote marks or the comma's on the above line. When this variation is used you get a tidy list of IP's, one from each test server, that looks like this:



    In the pic above the IP addresses are the known VPN public IP, so no DNS leak. Like outlined in the first post, if the addresses are not your VPN public IP then you have a DNS leak and the IP shown will be the IP address of the leaking DNS. Since there are always multiple DNS servers in the path, as explained in the first post, each test server may return a different DNS IP if a leak exists.

    The servers are tested in the reverse order (reading left to right - the last server first to the first one last) from which they appear in the command line. For example, if the servers in the line are ordered  <serv1>', '<serv2>', '<serv3>', '<serv4>' the testing order is  "<serv4>, <serv3>, <serv2>, <serv1>".

    Actually you only need one of the test servers and not four of them. I like doing it this way in case a server is down or times out  for some reason. If there is one down or timed out you don't have to switch to another single server line like in the original post. With the variation if one is down or times out it just moves on to the next test server in the 'list'

    In case a server is down or times out, an exception/error message will be returned by PowerShell which indicates the server could not be reached and a brief reason will be given. To keep from messing up your tidy IP list with that message, append this to the beginning of the command line:

    $ErrorActionPreference = 'SilentlyContinue' ;

    so it looks like this:

    $ErrorActionPreference = 'SilentlyContinue' ; ('whoami.fluffcomputing.com', 'resolver.dnscrypt.org', .... rest of line..

    With the 'SilentlyContinue' if a sever is down or times out nothing will be returned because the exception/error message is suppressed from showing so the number of IP's in the list (4 in this case, one for each server) will be decreased by the number of servers down or timed out. For example, if one server is down then only three IP's will be returned. I've never seen any of the test servers down or having an issue causing them not to respond or time out.

     Be careful with spelling of the server names if for some reason you type it from scratch. If the server name is not correct you will be wondering why that incorrectly spelled server is not working for you.

    Post edited by bgxsec on
  • edited June 2017 Posts: 173
    (If not familiar with use of the command prompt/line refer to the first post in this thread which indirectly outlines basics of command prompt use for this purpose, you'll get it after a little practice.)

    Windows and other commonly used operating systems (e.g. Linux, MacOS) already have a built in IPv6 leak test ability. There is no need to visit a web site somewhere to test when your own fingers can do it using what is already available in your OS.  For the Linux based OS and MacOS use '-c 1' in place of the below Windows ping example '-n 1', Linux and MacOS use 'Terminal'.

    Windows is used in the below examples, make the necessary adjustments for your OS if not Windows. An IPv6 leak test can be performed by using the 'Ping' method in a command prompt or a PowerShell method as described below.

    Command Prompt method - The PIA test version and others:

    The PIA IPv6 leak test at http://ipv6leak.com/ uses a literal IPv6 address ([2001:19f0:200:3d70:225:90ff:fec1:428c]) to conduct their test. The PIA test posits that If one can connect to this literal IPv6 address a IPv6 leak exists and if one can't connect an IPv6 leak does not exist. This can also be done in a command prompt with Ping, no need to visit the web page based test. This is the line format to use for the Ping method:

    ping [2001:19f0:200:3d70:225:90ff:fec1:428c] -n 1

    If there is no IPv6 leak the return should be either "General Failure" or "Ping request could not find host [2001:19f0:200:3d70:225:90ff:fec1:428c]"

    The next version of this is using the link 'https://ipv6.ipleak.net' where once again the ping method is used. This is the line to use:

    ping ipv6.ipleak.net -n 1

    If there is no IPv6 leak the return should be either "General Failure" or "Ping request could not find host ipv6.ipleak.net"

    The next version again uses another literal IPv6 address test, this time using a literal address used by the http://test-ipv6.com/ site. The line to use for this test is:

    ping [2001:470:1:18::119] -n 1

    If there is no IPv6 leak the return should be either "General Failure" or "Ping request could not find host [2001:470:1:18::119]"

    If the return is not that indicated above (with Ping returning packets RTT and the sort that looks like the site is actually responding to a ping) then there is an IPv6 leak. The below pic shows a return indicating 'no IPv6 leak' using the three test addresses above:



    PowerShell methods for IPv6 leak testing:

    The lines to use for the PowerShell methods using the given three test addresses used in the ping test above are:

    Invoke-WebRequest http://[2001:19f0:200:3d70:225:90ff:fec1:428c] | % {$_.StatusCode}
    Invoke-WebRequest http://[2001:470:1:18::119] | % {$_.StatusCode}
    Invoke-WebRequest https://ipv6.ipleak.net/ | % {$_.StatusCode}

    I know that some PowerShell users like to standardize how their code looks or prefer to use a certain formatting in their command lines. If you prefer, you can remove the '| % {$_.StatusCode}' and simplify the above lines a little by using a PowerShell popular line formatting like, for example, this:

    (Invoke-WebRequest http://[2001:19f0:200:3d70:225:90ff:fec1:428c]).StatusCode

    If there is no IPv6 leak the return should include either "The remote name could not be resolved" or "Unable to connect to the remote server" as indicated in the pic below:


    For the Invoke-WebRequest PowerShell method, if there is an IPv6 leak then the only thing that will be returned is "200" (which in web page/site status means OK, meaning the address could be reached and is working), meaning an IPv6 connection could be made to the address which means there is an IPv6 leak.

    Looking at the pic above, the return doesn't look very tidy. We know we need to get one of two things from the return - One, either a '200' which indicates we could make an IPv6 connection and thus have an IPv6 leak, or, Two, a "The remote name could not be resolved" or "Unable to connect to the remote server" which indicates we do not have an IPv6 leak. Since the non '200' return is actually an error message in PowerShell, we can leverage that knowledge to tidy up the return. To do this we want to use the $ErrorActionPreference = 'SilentlyContinue'; addition to the line like we did for the PowerShell DNS leak testing using the 'Invoke-WebRequest' cmdlet, this suppresses the display of error messages in PowerShell. To do so just add it in front of the line, for example:

    $ErrorActionPreference = 'SilentlyContinue';Invoke-WebRequest http://[2001:470:1:18::119] | % {$_.StatusCode}

    I intentionally created an IPv6 leak to produce the pic below. Using the $ErrorActionPreference = 'SilentlyContinue'; If there is an IPv6 leak a "200" will be returned and if no IPv6 leak the return will be blank - as seen in the pic below:




    The PowerShell Test-Connection cmdlet method can also be used, here are the lines:

    Test-Connection [2001:470:1:18::119] -Count 1
    Test-Connection [2001:19f0:200:3d70:225:90ff:fec1:428c] -Count 1
    Test-Connection ipv6.ipleak.net -Count 1

    For the Test-Connection method, if there is no IPv6 leak the return should include either "Test-Connection : Generic failure" or "Test-Connection : Testing connection to computer... <address here>  failed: No such host is known", as indicated in the pic below:

     
    The response for the Test-Connection method looks a little messy too, so like the Invoke-WebRequest method above we can clean it up with a modification to the command line. To do this we add the $ErrorActionPreference = 'SilentlyContinue'; and the display of the return message letting us know there was no leak is suppressed. But we still need an indicator telling us when there is a leak, so in this case we will select the ping response time to use as an indicator. It doesn't matter what the response time is, for this purpose we don't care because the fact that any response time is returned indicates an IPv6 connection was made to the test address and thus we have an IPv6 leak. The modification looks like this:

    $ErrorActionPreference = 'SilentlyContinue';Test-Connection '<address here>' -Count 1 | Select -exp ResponseTime

    Where the <address here> is located in the line replace it with one of the test addresses. If the return is a response time then you have an IPv6 leak (because the ping succeeded meaning an IPv6 connection was made). If the return is blank (meaning the ping failed and an IPv6 connection could not be made) then you do not have an IPv6 leak. The pic below was produced while there was an intentionally created IPv6 leak (first line with response time return of '57' in the pic below), and when the IPv6 leak was stopped (second line with blank return in the pic below). This is illustrated in the pic below:

     

    One can also use another 'indicator' for the return indicating there is or is not an IPv6 leak by getting the StatusCode. This method is shown in the line below:

    $ErrorActionPreference = 'SilentlyContinue';(Test-Connection [2001:470:1:18::119] -count 1).StatusCode

    If a '0' is returned it means the ping succeeded which means we made an IPv6 connection to the test address thus we have an IPv6 leak. If the return is blank it means the ping failed which means we could not make an IPv6 connection to the test address which means we do not have an IPv6 leak.

    Ok, so we have the above methods and there are many more variations too but this is not all inclusive. The reason I presented them as I did above is because PowerShell users sometimes have needs for different variations on methods, for example, sometimes I want to trap certain types of return errors. The old saying goes "There is more than one way to skin a cat", so now i'm going to show you the really easy PowerShell method by re-purposing a method used to detect if a site is up or down. We are once again using the Test-Connection cmdlet but changed a little to return either a 'True" (we have a IPv6 leak) or a 'False' (we do not have an IPv6 leak) by adding the -Quiet switch. The lines for this are below:

    Test-Connection [2001:470:1:18::119] -Quiet -Count 1
    Test-Connection [2001:19f0:200:3d70:225:90ff:fec1:428c] -Quiet -Count 1
    Test-Connection ipv6.ipleak.net -Quiet -Count 1

    Here is what it looks like for the True/False method by using the -Quiet switch:


    There ya go, nice n' neat IPv6 leak detection in PowerShell with a ping and a simple answer to the question "Do I have an IPv6 leak?" with a 'True' (we leak) or 'False' (we do not leak). Test-Connection is the PowerShell equivalent of the command prompt 'ping'. The same method is used by PowerShell folks to tell if a site is responding or not (up or down). In this case the method is applied in this context re-purposed and works because; If we can make an IPv6 connection to the test address then the 'site' is responding thus the 'True' is returned (we have an IPv6 leak) - If we can not make an IPv6 connection to the test address then the 'site' will not respond and thus a 'False' is returned (we do not have an IPv6 leak).

    Another method for IPv6 leak testing in PowerShell:

    This method involves using an IPv6 address detection site with an actual IPv6 endpoint that can be "forced" for an IPv6 lookup to detect the IPv6 address. Most sites which claim IPv6 address detection are really sites on IPv4 networks using Teredo transition technology to accommodate IPv6 and do not have an actual IPv6 endpoint. For IPv6 leak detection purposes here only use sites which have an actual IPv6 endpoint where IPv6 can be "forced" for an IPv6 lookup by the user (like the sites below). Below are two sites (there are others but these should be enough) with known reliability attributes and strict adherence to standards and their implementation. The command lines for these were already given in the first post in this thread at the very bottom of that post but are presented here again in this context, the command lines are:

    For PowerShell:

    (Invoke-WebRequest ipv6.whatismyip.akamai.com -TimeoutSec 20).Content
    Invoke-RestMethod v6.ipv6-test.com/api/myip.php?json -TimeoutSec 20 | Select -exp address

    With these if no IPv6 address is returned there is no IPv6 leak. The above two sites will also work in the Test-Connection True/False configuration that was described in this post, these are the lines:

    Test-Connection ipv6.whatismyip.akamai.com -Quiet -Count 1
    Test-Connection v6.ipv6-test.com -Quiet -Count 1

    (note: The '-TimeoutSec 20' was used for experimental purposes, left it in to show where it goes if you need it - a timeout is optional.)

    A special case - Teredo based IPv6 addresses: Most IPv6 leak test sites on the internet will not detect a Teredo based IPv6 address if there is an IPv6 leak as a result of Teredo, these sites stick to using standard IPv6 end point type detection in their tests. Even if you have the IPv6 protocol unchecked in your interface properties if there is a leak condition the Teredo based IPv6 address can still leak. Unchecking the IPv6 protocol in the interface properties DOES NOT disable Teredo or keep a Teredo based IPv6 address from leaking if an IPv6 leak happens. The Teredo based IPv6 address has your real ISP IPv4 address encoded in it and this can be eaisly decoded disclosing your real ISP IPv4 address even if you are on VPN. Therefore when considering testing for IPv6 leaks it wise to take Teredo into account. If you have not disabled Teredo in the OS you will be able to test for a Teredo based IPv6 leak in Powershell by using the below command line:

    (Invoke-WebRequest http://[2001:470:1:18::125]/ip/?callback=?"&"testdomain=test-ipv6.com"&"testname=test_ipv6).Content

    If the return is "Unable to connect to the remote server" then you do not have a Teredo based IPv6 leak. If the return is not that but instead includes an IPv6 address and the word 'Teredo' then you have a Teredo based IPv6 leak and the IPv6 address shown will be your Teredo based IPv6 address. For those who need more info on Teredo addresses here is something for you to read > Teredo Addresses

    Post edited by bgxsec on
  • Posts: 575
    Nice write up. I have IPV6 turned off on my router and my NIC. Whether that means anything I don't know since Windows basically does what it wants to do. However, I got the results expected... "Could not find host..."
  • edited June 2017 Posts: 173
    If you are using Windows 10 - 64 bit - with PowerShell: By request I quickly put together a small PowerShell based application for detecting DNS and IPv6 leaks using the PowerShell methods presented in this thread. The app is about 30'ish Kb in size, put it anywhere on your system. Simply run the app (as admin) and in several seconds it will display that in the pic below depending on if you have a leak or not.

     

    The leak information shown in the pic on the right above was a result of intentionally causing the software code to detect a leak condition during a final debugging run of the code for purposes of pic illustration immediately before it was compiled. The pic on the left is from an actual run of the application after it was compiled which shows a no leak condition. If you do have a leak the pic on the right gives you an idea of what the app will show you.

    There is no detection or error trapping in this for if you are or are not connected to VPN or for the OS type (although its intended for Windows 10, 64 bit, with PowerShell), or if PowerShell is installed or not. It's not PIA VPN specific and should be usable on any VPN service. It can be run off VPN which is useless because it doesn't matter there but like I said there is no trapping if the user is connected to VPN or not and its intended to be run on VPN. Took about 20 minutes to put together and compile and i'm not trying to win any awards with it... so...its as is and for demo purposes even though it works. Have fun.

    The link to download the app is > (no longer valid - get the latest version)
    The file is called '64bleaktest.exe'



    Post edited by bgxsec on
  • edited June 2017 Posts: 173
    A new version of the app - version 2.0 - whats new/changed:

    1. Can no longer run off VPN. This caused confusion for some people. Like I said in the post above for this app I was not trying to win any prizes with it and it only took me 20 minutes to put it together and compile so I did not add any detection as to if a user was or was not connected to VPN because I figured a person would know if they were connected to VPN or not. It is intended to be used on VPN only and not off VPN. Anyway, can no longer be run off VPN with this version, if you run it and are not connected to VPN it will tell you and not run any of the checks, thus this version is PIA specific.

    2. Added redundancy for all checks. If one resource is not available for some reason it will switch to using another to complete the checks.

    3. Some people got an IPv6 leak indication but they did not have a native IPv6 address assigned by their ISP, or had unchecked the IPv6 protocol in the interface properties, and could not understand why the app said they had an IPv6 leak but did not return an IPv6 address or even warned they have an IPv6 leak in the first place. Well, the reason is they did indeed have an IPv6 leak. Its an 'edge' case thing dealing with Teredo (and caching the Teredo IPv6 address) that rarely happens for 99.9% of people but here at PIA there are lots of different configurations people use for their systems and networks set up and I happen to get the .1% it did happen to :) so a new version. It was my fault for not telling about this with the first version. This was by design and not a bug or malfunction, as an indication that Teredo was still active on the system and generating an IPv6 address in the absence of a native IPv6 address, and could make an IPv6 connection under some conditions even on VPN if IPv6 leaks. I did not put in full code that detects if Teredo is active or not to check specifically for a Teredo based IPv6 address, so I relied on this indication in the first version demo testing but failed to mention it, sorry 'bout that. To prevent further confusion the app now displays the Teredo based IPv6 address if there is an IPv6 leak and the IPv6 address is not a native IPv6 address but rather one generated by Teredo in the OS when it tries to connect to an IPv6 site or end point. To those which bought this to my attention I thank you, but you were leaking IPv6 even though you had the IPv6 protocol unchecked in the interface properties so I recommend you enable IPv6 Leak Protection in the PIA client or disable Teredo in the OS.

    A word of warning and why an internet website based test for an IPv6 leak is not suitable: Unchecking the IPv6 protocol in the interface properties does not keep Teredo from working and still generating an IPv6 address and making an IPv6 connection under some conditions if there is an IPv6 leak. Basically, Teredo provides IPv6 connectivity by encapsulating IPv6 datagram packets within the IPv4 User Datagram Protocol (UDP) packets. The detection of the Teredo IPv6 address, by some internet  test sites checking for leaks with their test may fail to detect the Teredo IPv6 address when their test is run. Their test  generates a random alphanumeric 'token' for the test, the results are assigned to this token and then stored (cached) for a period of time while the user is still connected to the test site. The user is shown that everything is OK and there is no IPv6 leak, but an F5 refresh of the results display page (if it can be refreshed without the test being run again) then reveals there was indeed a leak and the Teredo IPv6 address is revealed. 99.9% of people never refresh the page to reveal the IPv6 leak. Some of them use a method that only tries to connect to an IPv6 address somewhere else which is not enabled to deal with a Teredo based IPv6 address even though the connection is made because they are not configured to do so, and fail to disclose the IPv6 leak when one actually exists because its using a Teredo based IPv6 address. 

    On VPN; A Teredo based IPv6 address can still make a connection under some conditions to an IPv6 only end point (if you hit one) or a dual stack IPv4/IPv6 site (which many are today) or an IPv6 site network which uses Teredo transition technology (which most places also use today) so it can be accessed via IPv4 connections. This can happen on VPN (if the IPv6 address leaks) unless you have either Teredo disabled. DO NOT, as some people on the internet would have you think, uninstall Teredo (or the 6to4 adapter - Windows 7) - simply disable it.

    To disable Teredo via PowerShell (Powershell v 2 and above) use the following command:

    Set-NetTeredoConfiguration -Type Disabled

    To disable Teredo (and the 6to4 - Windows 7) via netsh using the following commands in an admin command prompt window:

    netsh interface teredo set state type=disabled
    netsh interface ipv6 6to4 set state type=disabled < for Windows 7

    4. By request, added a version number in the bottom on the left under `the test information.

    Operation and file name is still the same as indicated in the post above for the first version. Still intended for Windows 10, 64 bit, with PowerShell.

    This is the link to download version 2.0 > (no longer valid - get the latest version)
    the file name is still '64bleaktest.exe'


    Post edited by bgxsec on
  • edited June 2017 Posts: 173
    A new version of the app - version 2.1 - whats new/changed:

    1. By request - Added Teredo enabled and active state status messages, and Teredo IPv6 address identification message, these are (depending on state status, or if IPv6 address is a Teredo address or not to aid in identification of an IPv6 leak source if it happens. These messages are:

    Teredo IS currently active on system.
    Teredo IS NOT currently active on system.
    Teredo IS ENABLED on system
    Teredo IS DISABLED on system
    (IPv6 address IS a Teredo address)
    (IPv6 address IS NOT a Teredo address)

    The messages are self explanatory but in addition for the Teredo IPv6 address identification message, if an IPv6 leak happens; The message '(IPv6 address IS a Teredo address)' tells you that the source of the address was Teredo and not from a native IPv6 address so Teredo is the source of the leak. The message '(IPv6 address IS NOT a Teredo address)' tells you that the source of the address was the native IPv6 address which means most times that you still have the IPv6 protocol selected in the connection interface properties. Even though the IPv6 protocol is unchecked in the connection interface properties its still possible to leak a Teredo IPv6 address (if there is an IPv6 leak). The Teredo IPv6 address has your real ISP IP address encoded in hex in the last 8 hex characters which can be 'decoded' eaisly, for example:

    2001:0:4146:e368:63ef:8000:c0a8:0405   <- c0a8:0405 is 192.168.4.135 (Example)

    2. Swapped out the PIA literal address test with another one as sometimes the PIA test will take longer than it should causing the Teredo test to fail or return null or time out. This increased wait times for the app to finish the test which means the user had to wait longer and one of the design things for this app was that it conduct the test quickly.

    3. Decreased spacing between test information lines.

    4. Identified and fixed a bug which in some (rare) cases could result in the DNS leak detection skipping a backup redundant test (if it was needed) by improperly truncating the return. Its highly unlikely anyone was affected by this as this test was a 'last resort' thing if the main test and the other four 'just in case' backups failed due to the addresses being unreachable for a user.

    5. Changed the VPN detection to include involving testing the IP address assigned to openvpn.exe (the gateway address) to determine if connected to PIA VPN or not. This is used only if the other three tests fail which is highly unlikely, but added to increase redundancy and to cover all uses.

    Operation and file name is still the same as indicated in the post above for the first version. Still intended for Windows 10, 64 bit, with PowerShell.

    Discard versions previous to this version (2.1).

    This is the link to download version 2.1 > (no longer valid - get the latest version)
    The file name is still '64bleaktest.exe'


    Misc notes: Like any app, sometimes your firewall might warn you its trying to connect. Simply add an exception for the app in your firewall or create a firewall rule allowing the app.



    Post edited by bgxsec on
  • edited June 2017 Posts: 173
    A new version of the app - version 2.2 - whats new/changed:

    1. Added a test method for IPv6 leak using the UDP protocol on port 53 which is protocol and port employed by ISP's, some DNS servers, and Chrome based browsers to test for global IPv6 connectivity, but also employed by others who want to snoop.

    2. Some changes to improve testing speed.

    3. A test server change from a secondary to a primary test server.

    Operation and file name is still the same as indicated in the post above for the first version. Still intended for Windows 10, 64 bit, with PowerShell.

    Discard versions previous to this version (2.2).

    This is the link to download version 2.2 > (no longer valid - get the latest version)
    The file name is still '64bleaktest.exe'


    (Please note that the link to download version 2.2 changed. I accidentally uploaded a previous version. The link that's posted now is version 2.2 and correct. So if you got the previous link download, discard it and get the one posted now. Sorry 'bout that)

    Misc notes: Like any app, sometimes your firewall might warn you its trying to connect. Simply add an exception for the app in your firewall or create a firewall rule allowing the app. 




    Post edited by bgxsec on
  • edited June 2017 Posts: 173
    A new version of the app - version 2.3 - whats new/changed:

    1. Expanded upon IPv6 leak detection to include a condition for Windows 10 and PIA VPN combination where a native or Teredo Global or a non-Global IPv6 address can actually make an IPv6 connection once connected to VPN for a short period of time if Teredo or a native IPv6 address is active on the system, even if IPv6 leak protection is enabled. This situation happens when a person has been connecting to sites or endpoints on the internet by some method (browsing, etc...) off VPN and either has a native or a Teredo IPv6 address active then connects to VPN and starts internet traffic as soon as connected (PIA icon turns bright green). In some cases up to about a minute (depending on system) after connecting to VPN its still possible for one of these IPv6 addresses to establish a connection to an IPv6 address within an IPv4 network, or a site/endpoint, that uses Teredo transition technology if the user starts their internet activity as soon as connected. The PIA IPv6 leak protection does not stop this conditional leak from happening. The fact that an IPv6 connection can be made while the VPN is connected means the possibility exists for an IPv6 leak.  If there is not supposed to be an IPv6 leak on VPN with IPv6 leak prevention enabled then no IPv6 address on your system should be able to make any IPv6 connection via TCP or UDP once the VPN is connected. This issue is of concern because its an IPv6 connection to your system indicating a leak that can still possibly expose the global Teredo IPv6 address leading to your real ISP and you being discovered. If this condition is detected by the app the warning message given will be "Warning! Possible IPv6 Leak Condition" and the leak IPv6 address is shown. Teredo can still perform its function even from behind network address translation (NAT) devices such as home routers.

    If connected to VPN less than a minute and you run the app and this condition is detected, wait a minute longer then run the app again to make sure the condition has gone away before you start going places on the internet. If the condition persists after this then you have a issue that needs to be resolved. The resolution is making sure the IPv6 protocol is unchecked in the interface properties and disabling Teredo (do not uninstall Teredo). If this condition is not detected by the app then you are good to go. This is a condition which has, in two known cases in the last month, resulted in VPN users being compromised while using VPN due to their Teredo IPv6 address being exposed. The Teredo address has your real ISP assigned IPv4 address encoded in hex in the last eight hex characters of the Teredo address and can be eaisly decoded'. Test web sites for DNS and IPv6 leak will not detect this condition. Users can now test for this condition with the app, and as far as I can tell right now its the only detection test available (as of this posting) which will test for this condition so that makes it an original and the only one and also a sort of 'exclusive' for PIA users. 

    2. There are now two possible warning messages given dealing with IPv6 leak's, these are:

    Warning! Possible IPv6 Leak Condition (see item 1 above)
    Warning! Detected IPv6 Leak (if you have an actual IPv6 leak)

    and if there is no IPv6 leak (actual or possible) the message will still be:

    No IPv6 Leak Detected

    3. Added identification of the IPv6 address type to aid in identifying IPv6 leak source and judging risk of exposure.

    4. Added identification of IPv6 addresses given with an IPv6 leak warning message as to if the address is "Global". This will appear below the IPv6 address type identification in the event an IPv6 leak is detected or a possible IPv6 leak condition is detected. If an IPv6 address is "Global" it basically means its route'able on the internet which also includes your Teredo IPv6 address and/or your ISP provided native IPv6 address.

    5. Removed the Toredo active/not active/enabled/not enabled/ is Toredo/is not Toredo messages previously implemented in version 2.1 after implementing the IPv6 addresses type identification in item 4 above.

    Operation and file name is still the same as indicated in the post above for the first version. Still intended for Windows 10, 64 bit, with PowerShell.

    Discard versions previous to this version (2.3).

    This is the link to download version 2.3 > (no longer valid - get the latest version)

    The file name is still '64bleaktest.exe'

    Misc notes: Like any app, sometimes your firewall might warn you its trying to connect. Simply add an exception for the app in your firewall or create a firewall rule allowing the app.




    Post edited by bgxsec on
  • edited June 2017 Posts: 173
    A new version of the app - version 2.4 - whats new/changed:

    1. Optimized detection code with faster methods.

    2. Changed GUI from message box style to window style. Window color changes according to status - Red if there is a DNS or IPv6 (or both) leak or possible IPv6 leak condition, Green if there are no leaks, as illustrated in the pic below:

    3. Replaced some conditional code to better define detection of Global IPv6 addresses.

    4. Slight operation change: There is no more OK button, instead to close simply click the X in the upper right corner. Start up the app and in up to several seconds the results window should appear when the test is complete (as indicated in the pic above) letting you know the status of things. If it takes longer than several seconds it doesn't necessarily mean anything is wrong, just that your particular connection is probably slower for reaching the various test servers. (note: The test starts as soon as you start the app, there is no indication of it running until the results window appears.)

    5. Version number moved from bottom left to bottom right.

    The app is still intended for Windows 10, 64 bit, with PowerShell.

    Discard versions previous to this version (2.4).

    This is the link to download version 2.3 > (no longer valid - get the latest version)


    The file name is still '64bleaktest.exe'

    Misc notes: Like any app, sometimes your firewall might warn you its trying to connect. Simply add an exception for the app in your firewall or create a firewall rule allowing the app.




    Post edited by bgxsec on
  • edited June 2017 Posts: 173
    A new version of the app - version 2.5 - whats new/changed:

    1. In response to request; Added detection for a condition with PIA client where it indicates connected to VPN via being bright green but is not actually connected, and can not browse or connect to any site. If this condition exists when the app is run the message shown will be "Warning! Not connected to Internet". (note: the same message will also be shown if you are not actually, you know, connected to the internet :) or not able to get a valid public IPv4 address.)

    2. In response to request: Added basic gateway information of connected gateway name and IPv4 address, as shown in the pic below:



    The app is still intended for Windows 10, 64 bit, with PowerShell.

    Discard versions previous to this version (2.5).

    This is the link to download version 2.5 > http://www23.zippyshare.com/v/PkHMz4mS/file.html

    The file name is still '64bleaktest.exe'

    Misc notes: Like any app, sometimes your firewall might warn you its trying to connect. Simply add an exception for the app in your firewall or create a firewall rule allowing the app.

    Note: This will probably be the last version of the app. I've switch over to using AirVPN and very soon my PIA subscription will expire and I will no longer be posting here when that happens. I hope you got some useful information from this thread and it has helped you.
    Post edited by bgxsec on
  • edited June 2017 Posts: 575
    Thanks for all that you done here. Much appreciated. Good luck with AirVPN.
    Post edited by Omnibus_IV on
Sign In or Register to comment.