How do I check a VPN for leaks?
How to make sure that all traffic goes through the VPN tunnel? What happens if everything seems normal after turning it on, but your computer goes to sleep and wakes up again? Or if there's a network connection interruption? What if you're using Wi-Fi and switch to a new access point and network? Or if you connect to a network that fully supports IPv6? This guide will show you how to conduct a comprehensive VPN leak test.
First, make sure that the VPN tunnel is configured on your computer. In Windows, open the command prompt and run the command ipconfig /all. You will see an Ethernet adapter section with a description like "WireGuard Tunnel" or "TAP-Windows Adapter V9." The IPv4 address will look like 172.x.y.z or 10.x.y.z. In macOS and Linux, open the terminal and run the command ifconfig. In macOS, the VPN tunnel adapter is named utun0, and in Linux, it's either wg0 or tun0.
Risks of Browser Fingerprint and IPv6 Leaks
The only way to ensure that all traffic is routed through the VPN tunnel is through testing. However, VPN leak testing comes with certain risks. Websites used for testing may detect identical browser fingerprints from both the IP address assigned by your provider and the VPN exit IP address. Any malicious actor who obtains your browser fingerprints can potentially identify you, even if you're using a VPN and/or Tor, as long as you're using the same browser. In a recently published W3C guide project, it states:
"The claim that browser fingerprinting can be eliminated as a threat solely through widely deployed technical means is implausible."
WebGL fingerprints and IPv6 leaks are more serious concerns. WebGL utilizes the graphics processor through the OS graphics driver. All browsers on a specific system with WebGL enabled will share the same WebGL fingerprint. It's recommended to block WebGL when using VPN services. For instance, in Firefox, you can go to "about:config" and set "webgl.disabled" to "true." In the NoScript options under the "Embeddings" tab, check "Forbid WebGL."
Systems using the same graphics driver may have identical WebGL fingerprints, even if the OS is reinstalled or switched to another OS with the same graphics driver. This can be observed with VirtualBox virtual machines that use the default virtual GPU. For example, browsers on Debian and Lubuntu VMs will have the same WebGL fingerprint. However, browsers on different OSes (various Linux distributions, FreeBSD, Windows, and macOS) will have different WebGL fingerprints. Host and VMs use different graphics processors (real and virtual), so their WebGL fingerprints don't overlap.
VPN clients often unintentionally leak IPv6 traffic, which is a significant concern because IPv6 addresses are typically device-specific. Therefore, it's advisable to disable IPv6 in both the OS and local network router. Using VPN clients that block IPv6 traffic or configuring your firewall to block IPv6 is also a wise choice. Additionally, whenever you connect to a new local network or Wi-Fi network, check for IPv6 connectivity.
By the way, WebGL fingerprinting is a crucial topic when dealing with multiple VMs. You can easily block WebGL fingerprints in browsers, but it's also reasonable to separate VMs with different WebGL fingerprints. Whonix is another good option, as the Tor browser used in this OS has been strengthened to completely block WebGL fingerprinting.
Check
During VPN leak testing, you can use the tcpdump program to check for traffic not using the VPN tunnel. In Windows, you'll need Wireshark and wintee. Simply place copies of them in the user folder.
Now, list the network interface numbers:
sudo tcpdump -D
You'll need a physical network interface. Usually, it's "1". So, to start capturing:
tshark -i 1 -n -T text -w "C:\tshark-capture.log" -f "not host a.b.c.d" 2>&1 | wtee tcpdump.log
sudo tcpdump -n -i 1 not host a.b.c.d 2>&1 | tee tcpdump.log
sudo tcpdump -n -i 1 not host a.b.c.d 2>&1 | tee tcpdump.log
The host a.b.c.d is your VPN server. During the following tests, keep the command prompt/terminal window open and look for packets with addresses outside your local network and/or Wi-Fi network.
Start by checking your IP address. It's safest to use your VPN provider's website. If they don't provide your IP address, the next safest option might be the check.torproject.org website. If you plan to test VPN leaks using other websites, it's recommended to use the Tor browser since it has been enhanced to block WebGL fingerprints and otherwise provides uniform fingerprints for all users. But for now, you can use the default browser. In any case, you should see your VPN exit IP address.
You'll also need a steady source of network traffic. In a second command prompt/terminal window:
ping -t a.b.c.d 2>&1 | wtee ping.log
ping -n a.b.c.d 2>&1 | tee ping.log
ping -n a.b.c.d 2>&1 | tee ping.log
If you want to use timestamped pings in Windows or macOS, you need some hacks (more or less cumbersome):
ping -t a.b.c.d | cmd /q /v /c "(pause&pause)>nul & for /l %a in () do (set /p "data=" && echo(!time! !data!)&ping -n 2 localhost>nul" 2>&1 | wtee ping.log
macOS:
ping -n a.b.c.d | while read pong; do echo "$(date): $pong"; done 2>&1 | tee ping.log
Linux:
ping -D -n a.b.c.d 2>&1 | tee ping.log
Some VPN providers' custom clients block pings to their servers through VPN tunnels. If there's no response, press Ctrl+C and try pinging a.b.c.1. If that doesn't work either, try connecting to the server 38.229.82.25 (torproject.org). In the traffic capture window, there should be no packets with addresses outside the local LAN and/or Wi-Fi network (i.e., non-local traffic is not captured).
Now, disconnect your machine from the network. In Windows, you'll see a "Request timed out" message. In macOS and Linux, ping output will simply stop. Then, reconnect your machine to the network. If everything is fine, ping responses should reappear. Refresh the IP-checking website in your browser. You should still see your VPN exit address. In the capture window, there should still be no non-local captures. In Windows, you might observe a lot of local traffic. For a more thorough check, you can view the tcpdump.log file in a text editor.
Disconnected Connection
Issues with a disconnected connection manifest in a few main ways. Let's assume you are using OpenVPN. The most apparent scenario is when the openvpn process (not just the VPN connection) terminates after losing network connectivity. So, when the network connection is restored, the IP-checking website will report the provider-assigned IP address. You will also see numerous captures of non-local traffic. By the way, Network Manager in Linux tends to behave this way, so it's advisable to avoid it.
A less obvious but more insidious scenario is when the VPN client reconnects after network restoration, and the IP-checking website still reports your VPN exit IP address. You might not notice any connectivity interruptions, but you'll see captures of non-local traffic generated by pings that were successful before the VPN tunnel was restored. Just one packet leaking out is enough to reveal the provider-assigned IP address.
Simple OpenVPN tends to have issues that are somewhat simpler but still problematic. If a network disruption is long enough to destroy the VPN connection, OpenVPN cannot recover it. While OpenVPN is running, all traffic is directed through the non-functioning VPN gateway, and the network connection is effectively lost. Pings will fail, and you won't see any traffic captures. Default routing isn't restored until the openvpn process is killed. So, you can close applications that require access to critical network resources, kill the openvpn process, and then reconnect to the VPN. Or, you can simply reboot. However, these are tedious actions prone to errors.
You can employ a similar approach to observe how your VPN client reacts to other disruptions. Transitioning to sleep mode and resuming, changing Wi-Fi access points, or using a network with full IPv6 connectivity – it doesn't matter. Checking the tcpdump.log and ping.log logs should reveal any leaks.
If you find that your VPN client has leaks, one option is to try another VPN provider and test its client. However, in Linux, it's easy to block leaks using vpn-firewall from adrelanos. We recommend using it with the built-in openvpn service, not Network Manager. In principle, it allows all applications to use the VPN tunnel while blocking everything except connections to the VPN server on the physical interface. You can apply the same firewall logic in Windows and macOS. In Windows, you can simply use the Windows Firewall. In macOS, you can use IceFloor, which is a graphical interface for the PF firewall in OpenBSD.
Other Types of Leaks
Even if all your traffic is routed through VPN, it's possible that DNS queries are sent to a DNS server controlled by your ISP or associated with it. Even if the queries go through the VPN exit, an adversary observing the DNS server and ISP traffic can correlate the activity. If the VPN server uses the same IP address for entry and exit, this correlation becomes trivial. Now, the malicious actor knows which websites you're visiting.
The HTML5 Geolocation API can potentially lead to significant leaks. It caches and reports available location data. Perhaps you've shared your location to get local weather information. If you're using Wi-Fi, your location can be triangulated based on available access points. If you're on a smartphone, your approximate location can be determined based on the base station identifier. Plus, your GPS might be turned on. However, this isn't an issue as long as only your IP address information is available.
WebRTC is another hazardous HTML5 feature. If it's enabled in your browser, it reveals your local IP address. If IPv6 is in use, it discloses the local IPv6 address, which usually depends on the specific device. To prevent WebRTC leaks, it's advisable to install the "WebRTC Control" browser add-on. As mentioned earlier, it's also wise to disable IPv6 in your OS and block all IPv6 traffic in your firewall.
Visited websites can also be estimated based on the number of intermediate routers by inspecting received SYN packets. The Time to Live (TTL) for SYN packets defaults vary depending on the OS. The User-Agent string of the browser identifies the OS. As the packet passes through routers, the TTL value decreases. The difference between the expected and observed TTL values allows for estimating the number of intermediate routers.
If you plan to test leaks using third-party websites, we recommend using the Tor browser since it implements WebGL fingerprinting blocking and otherwise reports the same fingerprints for all users. However, you probably don't want to use Tor for VPN testing. First, download the Tor browser for your OS. Do this while connected to the VPN so that your provider doesn't see it. After extraction, start the Tor browser. You can likely accept all default settings. Go to advanced network settings and select "No proxy." Review about:config and set both "extensions.torlauncher.start_tor" and "network.proxy.socks_remote_dns" to "false." Then, go to the check.torproject.org website. You should see a message stating that you're not using Tor and displaying your VPN exit IP address.
You cannot investigate WebGL and other fingerprints using the Tor browser. If you decide to conduct testing with other browsers, be extremely cautious. As mentioned earlier, all WebGL-supporting browsers on the same system will have the same WebGL fingerprint. Therefore, avoid using the same system with and without a VPN connection. Also, avoid using different VPN services unless you're unconcerned about associating the system with both. Additionally, if you're using virtual machines, refrain from using linked operating systems with and without VPN and with different VPN services.
Conclusion
Here are the main tests and the expected results you should aim for:
1. IPv6 address test: No IPv6 addresses detected.
2. IP address test: Expected IP addresses with VPN on and off.
3. Geolocation test: Browser does not support geolocation API.
4. Java test: Java not found or disabled.
5. WebGL test: WebGL blocked by NoScript.
6. WebRTC test: WebRTC not enabled.
7. Panopticlick: Browser protected against fingerprinting.
8. DNS Leak Test (use extended test): Different DNS servers with VPN on and off.
The material is based on the original article: https://telegra.ph/Kak-vypolnit-proverku-VPN-na-utechki-10-08