This link should work: https://i.rtings.com/assets/pages/haZFh2ib/protonmullvad-wireshark-20250429.zip
And for DNS resolution our ISP DNS is: 207.164.234.129
Let me know if you have any additional questions.
1 Like
We’re listening to your feedback and we’re in the early steps of adjusting our definition of what is a leak. Based on your knowledge where should we draw the line?
What I had in mind is allow:
- DNS queries to a known server(or ISP) for the VPN server, outside the tunnel.
- API calls to the VPN API (e.g: Grizzlybear for Tunnelbear), outside the tunnel.
- Any TLS or other handshake process during the initial connection and reconnection. However, this means the VPN should not reconnect once connected, unless we made the connection fail as part of our tests.
What we would still likely consider a fail is:
- Calls to anything but the VPN servers/API during a vpn failure (crash, reboot, replug cable)
- DNS query for anything but the VPN servers/API outside the tunnel once connected.
Do you all find this more fair and realistic?
Big thanks,
CL
6 Likes
This makes sense to me 
1 Like
Hi everyone,
VPN 0.9.1 has been published and addresses the issues that were raised here.
The reviews and the article have been updated. In summary these VPNs have improved with the adjusted definition of a leak: ExpressVPN, NortonVPN, IVPN, Mullvad, Proton VPN and Windscribe.
Thanks again for the feedback!
11 Likes
And thank you for being open to feedback, not a lot of websites are open to it these days, let alone taking it via a third partt forum, so kudos for that!
6 Likes
Although the tunnel has already been created, so why is this client trying to connect to an ip from outside the tunnel to an ip (100.64.100.1) in the rfc6598 shared address range? It also looks like there is no response to the client from that ip. Does that ip belong to a local service running on the pc or is the traffic actually leaking to the ISP?
That’s the CGNAT address range that’s increasingly being used by VPN providers for “inside the tunnel” traffic so as not to conflict with the Private IPv4 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). I know at least Tailscale does so.
Without advanced routing systems like Linux network namespaces or macOS’s NECP, if your router claims 10.0.0.0/8 and your VPN service’s gateway is inside that subnet, you are in for a wild ride in terms of unexpected routing loops and hijinks.
1 Like