If this test shows red, your real IP address is leaking. Your IP address is tied to your identity and location through your internet provider.

These are some of the most common reasons that this can occur:

• IPv6 leaks: We now support IPv6, so this should no longer be an issue. OpenVPN users should be able to use IPv6 without changing anything, unless it's blocked. WireGuard users who generated their configs prior to October 1, 2024 should use cryptostorm.is/wireguard_man to see what their local IPv6 address should be (it starts with fd00:10:10:). They would need to add it to the Address = section of their config, and add ::/1 to the AllowedIPs = section (::/0 if using the built-in killswitch). Address and AllowedIPs accept multiple IPs separated by commas, so don't replace the IPv4 address, add the IPv6 one after it using a comma to separate the two. That or just generate new configs.
• OpenVPN not running: If something causes the OpenVPN process to terminate abruptly (crash, or another program closes it [Antivirus, another VPN provider's client, etc.] then your real IP will leak, if you're not using a killswitch.
• Split tunneling misconfiguration: If you're doing split tunneling, certain traffic is routed outside the VPN. This could cause a leak if the split tunneling allows more traffic than intended to bypass the VPN.
• Local proxy: If your browser is setup to use an HTTP(s) proxy that's in your LAN, it could bypass the VPN if you're not using a killswitch.

Mitigation

To prevent your real IP address from leaking:

• Use a killswitch: Our Windows client includes a killswitch (disabled by default). For Linux users, we have several killswitches to cover a variety of scenarios.
• Make sure no other VPN software is running: Most VPN providers use software that assumes they're the only VPN that will ever be used on your system, so they have a habit of trampling over other VPN's network interfaces. You can multihop with us and any other VPN provider that supports OpenVPN or WireGuard, but you usually can't do it directly from another VPN provider's software. See cryptostorm.is/multihop for more info on multihopping with OpenVPN, and cryptostorm.is/blog/multihopping-wireguard for multihopping with Wireguard.
• Double check split tunneling configuration: Make sure any split tunneling you may be doing is only allowing the specific IPs/programs that you want to exclude from the VPN. Use specific prefixes for IPs (/32 for IPv4, /128 for IPv6) as opposed to broader prefixes like /24 for IPv4 or /64 for IPv6.
• Make sure your browser isn't configured to use a proxy: If your browser is using a proxy server that's hosted on another system in your LAN, it can bypass the VPN if you're not using a killswitch.

If this test shows red, your DNS is leaking. This could lead to deanonymization because it means your DNS requests are being sent outside the VPN tunnel, exposing your browsing activity to your ISP and potentially other third parties.

DNS leaks can result in:

• Exposure to ISPs: When your DNS is leaking, your ISP can see the websites you visit, even if your other internet traffic is encrypted. This compromises the privacy that the VPN is supposed to provide.
• Third-party tracking: DNS leaks can also expose your browsing history to third-party DNS servers, which can log and monitor your activity without your knowledge.
• Targeted advertising: With access to your DNS queries, advertisers can build a profile based on your browsing habits, leading to targeted ads and tracking.
• Location leaks: DNS leaks can reveal your true location, maybe not your specific address but at least the general area (city/state/country), and which ISP you use. This could be useful in correlation attacks.

Mitigation

To prevent DNS leaks:

• with WireGuard, on Windows: Use the built-in killswitch.
• with OpenVPN GUI or our client on Windows: Both should be using the OpenVPN --block-outside-dns feature to prevent DNS from going anywhere outside of the VPN tunnel. If, for whatever reason, you've setup your config to ignore this directive that's pushed from the server, you should make sure your DNS is always set to 10.31.33.8 while connected to the VPN (10.31.33.7 for the ad/tracker blocking DNS). Use 2001:db8::8 for IPv6, 2001:db8::7 for ad blocking.
• with WireGuard, on Linux: Follow the directions for your distro on the Linux instructions page. At the very least, make sure that resolvconf is installed so that your DNS will be updated, but a better solution is to use PostUp/PostDown and iptables to force all DNS traffic to go to 10.31.33.8 (or 10.31.33.7 for ad/tracker blocking).
• with OpenVPN, on Linux: Follow the directions for your distro on the Linux instructions page. At the very least, use the /etc/openvpn/update-resolv-conf script that most distros come with, but a better solution is to use a --client-connect/--client-disconnect script that uses iptables to force all DNS traffic to go to 10.31.33.8 (or 10.31.33.7 for ad/tracker blocking). If you're using NetworkManager to connect, you can do the same with a dispatcher script.
• Disable DNS-over-HTTPS in your browser: DNS-over-HTTPS (DoH) does encrypt your DNS, but it sends it to a third party (usually Cloudflare or Google) who could be monitoring your DNS queries. DoH is unnecessary while on a VPN, if using the VPN server's 10.31.33.8 or 10.31.33.7 DNS servers because the DNS is already encrypted by the VPN tunnel.

If this test shows red, your real IP(s) could be leaking. If it's yellow, then you're only leaking local IPs (192.168.x.x or 10.x.x.x, for example), which aren't as bad as your public IP, but can still be useful in correlation attacks. Deanonymization through WebRTC can occur because WebRTC requires the real IP address of a user to establish direct peer-to-peer connections. This process involves contacting STUN servers to determine the public IP address of the user. While this is essential for enabling direct connections, it can inadvertently reveal a user's true IP address even when they are connected to a VPN.

Mitigation

To prevent WebRTC from leaking real IP addresses, users can:

• Manually disable WebRTC in the Browser
  In Firefox you can disable WebRTC by typing about:config in the address bar then searching for media.peerconnection.enabled and changing the value to false.
  In Chrome, there is no setting that allows you to completely disable WebRTC, so use an addon instead.
• Use a browser addon that disables or limits WebRTC functionality: We recommend WebRTC Control because it's open source and easy to enable with a single click. It supports Chrome, Opera, FireFox, and Edge. It's source code is available on GitHub.
• Use a newer browser: Almost every modern browser includes a feature that will obfuscate IPs, or at least limit WebRTC to the active interface only. You should always be using the latest version of whatever browser you prefer. Using older browsers will make your system less secure.