Is there a way to verify if a Windows VPN client is properly blocking IPv6 leaks without third-party tools?

Question

Is there a way to verify if a Windows VPN client is properly blocking IPv6 leaks without third-party tools?

Amir 0

I'm currently evaluating a VPN client on Windows 11 (version 23H2) and I want to make sure it's not leaking my real IP address through IPv6. The client claims to have "advanced leak protection," but I prefer to verify this myself using built-in Windows tools rather than relying on the vendor's claims.

I found a security-focused site that mentions some testing methods (turbix.me), but the instructions are a bit vague. Could someone explain the standard procedure to check for IPv6 leaks on Windows using native tools like netstat, PowerShell, or the Windows Filtering Platform? Specifically, I want to know:

Which commands can reliably show if IPv6 traffic is bypassing the VPN tunnel?

Are there any known registry settings or group policies that affect how Windows handles IPv6 when a VPN is active?

Is there a difference between how OpenVPN, WireGuard, and proprietary protocols handle IPv6 leak prevention on Windows?

Thanks for any guidance.

0 comments

1 answer

Your answer

Answer 1

netstat can show you that IPv6 connections exist, but this doesn't by itself prove that those connections went through the VPN. Try instead establishing a known IPv6 connection while the VPN is connected and determine which Windows interface and route are carrying it. Before connecting the VPN, record your interfaces and routes with the following commands.

ipconfig /all
Get-NetIPInterface -AddressFamily IPv6
Get-NetIPConfiguration
Get-NetRoute -AddressFamily IPv6 | Sort-Object DestinationPrefix,RouteMetric

After connecting the VPN, run those same commands again. Look for the VPN tunnel interface, such as a TAP or Wintun adapter, and compare the IPv6 routes. For a full-tunnel VPN, IPv6 traffic should either be routed through the VPN interface or explicitly blocked so it cannot use the physical Ethernet or Wi-Fi interface.

Focus on the IPv6 default route.

Get-NetRoute -AddressFamily IPv6 -DestinationPrefix "::/0"

If Windows has an active ::/0 route through your physical network interface while the VPN claims to provide full-tunnel protection, that deserves investigation. Simply seeing an IPv6 address assigned to your physical adapter does not prove that there is a leak.

netstat is useful for seeing actual IPv6 TCP connections.

netstat -ano -p tcpv6

In PowerShell, you can also use:

Get-NetTCPConnection | Where-Object {$_.RemoteAddress -like ":"}

These commands show IPv6 connections, but they do not reliably tell you which network interface carried each connection. Therefore, seeing an IPv6 connection does not automatically mean that IPv6 bypassed the VPN.

You can test IPv6 connectivity with:

Test-NetConnection -ComputerName ipv6.google.com -Port 443

For more detailed routing information, use:

Test-NetConnection -ComputerName ipv6.google.com -DiagnoseRouting -InformationLevel Detailed

An external IPv6 test that reports your public source address is still the most definitive way to determine whether your ISP's IPv6 address is escaping the VPN. If the external service sees your normal ISP-assigned IPv6 address while the VPN is connected, you have an IPv6 leak.

Windows Filtering Platform (WFP) provides a deeper way to investigate this. Windows can audit WFP connection events through the relevant Windows auditing policies, with the resulting events appearing in the Security event log. You can also inspect Windows Firewall configuration with:

Get-NetFirewallProfile
Get-NetFirewallRule | Where-Object {$_.Enabled -eq "True"}

This is useful for determining whether the VPN client has installed firewall rules that block traffic through the physical adapter when the VPN is active or disconnected.

AFAIK, there is no universal Windows registry setting called "VPN IPv6 leak protection." One IPv6-related registry value worth checking is:

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\DisabledComponents

You can inspect it with:

Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" -Name DisabledComponents -ErrorAction SilentlyContinue

However, disabling IPv6 globally is not equivalent to VPN leak protection and can interfere with Windows functionality. Group Policy can also control IPv6 behavior and transition technologies, but VPN leak protection is generally implemented by the VPN client through routing and Windows Firewall/WFP rules.

OpenVPN, WireGuard, and proprietary VPN protocols can behave differently. OpenVPN can carry IPv6 through the tunnel if the client and server are configured for IPv6, or the VPN application can block IPv6 outside the tunnel. WireGuard can similarly route IPv6 through the WireGuard interface, but WireGuard itself does not automatically provide a complete Windows kill switch. Commercial VPN applications frequently add Windows Firewall/WFP rules around the underlying protocol to prevent traffic from escaping when the tunnel fails. Consequently, two VPN applications using different protocols can have very different IPv6 leak behavior.

So for your evaluation, test three conditions: VPN disconnected, VPN connected normally, and VPN connected while deliberately disrupting the VPN connection. In each condition, check the IPv6 default route with:

Get-NetRoute -AddressFamily IPv6 -DestinationPrefix "::/0"

Check active IPv6 connections with:

Get-NetTCPConnection | Where-Object {$_.RemoteAddress -like ":"}

Then test IPv6 routing with:

Test-NetConnection -ComputerName ipv6.google.com -DiagnoseRouting -InformationLevel Detailed

The third test is important because a VPN may correctly route IPv6 while connected but still allow IPv6 traffic to escape when the tunnel fails if its kill switch does not block the physical interface.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin