VPNs that are listed on PG such as: Mullvad, IVPN, ProtonVPN leaks on reboot, author tested on Windows, will be grateful if someone tested it on Linux.
Interesting but the article lacks details, doesnât say whether they enabled Mullvadâs Lockdown mode or just went with the standard Kill Switch
I seriously doubt if Mullvad with Lockdown Mode, IVPN with its Kill-switch, or any VPN set up via the terminal with Wireguard with kill switch enabled leaks traffic.
They say they are using a straight forward set up. Meaning default settings. Itâs not the best way to test because they are ignoring other settings and features that ensure no traffic is leaked.
I donât buy it. This is clickbait and not done in good faith.
They tested it on Windows, so I doubt this applies. They did explain how to setup firewall rules to avoid those leaks.
Many VPNs advertise a kill switch that blocks all unencrypted system traffic in case it disconnects, such as if your internet drops, your computer restarts, or the VPN client crashes. However, it may not always be called a âkill switch;â some call it firewall mode or lockdown mode, for example.
They are clearly (IMO) referring to using this optional feature throughout this article, not just default settings, so yes they have enabled the kill switch properly.
Their testing indicates Mullvad leaks following a reboot but not when internet is lost or the client crashes.
Edit: 
1 Like
Upon further reading, their conclusions are flawed, because they consider connections to the VPN providerâs own servers a leak.
Norton VPN leaks to its own servers. We know this because we monitored DNS queries from our system to our ISPâs DNS, something they could log. The DNS query shows that we are trying to find an IP address belonging to the Avast network.
In ExpressVPNâs case, we saw a DNS query sent to a server that was most likely their own, which is expected. However, the request was not in the tunnel, so your ISP or other third parties would be able to inspect the packet and see that youâre trying to connect to ExpressVPNâs servers.
This makes no sense at all, because your ISP or other third parties will always be able to see youâre connecting to ExpressVPNâs servers regardless of whether that connection is inside a VPN tunnel.
I am not sure whether this is also the case with Mullvad, IVPN, and ProtonVPN in their testing, since they didnât clarify their results for any of those providers, so further investigation is still needed. But you canât take their claim that leaks exist simply at face value.
Our strict testing criteria means that we consider any DNS queries outside the tunnel to be leaks. We donât capture the initial connection, so if the VPN needs to do an initial DNS query to connect, that will not fail our tests. However, since our kill switch tests do, if a VPN makes a non-tunneled DNS call to reconnect, we will consider it a leak. It would be better for VPNs to cache the server IP until the tunnel is reestablished so that it doesnât need to query its API servers on the open Internet every time to reconnect.
This feels like they do not understand the threat models of commercial VPNs.
5 Likes
Use vpn within a rented virtual server (monero). eZ PZ
What rented server accepts Monero?
PrivateAlps and Hiddence. Both offer windows RDP.
Hiddence is fully no KYC (crypto only, no online presence, shady ASN)
PrivateAlps is good option as well but the owner has presence on a lot of clearweb sites.
I consider me not being able to find the real owner a good no-kyc provider.
https://kycnot.me/ lists more options if you donât like these.
Rented servers donât offer much privacy, the only privacy if offers is privacy from your ISP, but since you are the only one using that IP, websites can tie your activity.
1 Like
In Windscribe review, it seems that they define the robustness of a killswitch with the following criteria
Please donât have this mindset. Any computer thatâs not the one in your room offers much more privacy and plausible deniability. This is why you choose a reputable âmoneroâ host and not something like Azure. But this post concerns preventing IP leaks in case you donât trust your VPN kill switch. [VPN > RDP > VPN within RDP] or [RDP > VPN within RDP] depending on your threat model. Of course you should still avoid putting a lot of PII in a RDP and shouldnât use it for anything that could connect your real identity. Services like Hiddence have a API and a daily plan so you could theoretically create iOS shortcuts to nuke your RDP and create new oneâs whenever you desire without emptying your pockets.
Itâs all about threat models. How much more privacy can be gained by using a rented server? I imagine most of the leaks users will be on users host OS, unless the user plans on running a VM on a VPS to do all web activity. For many, this is a very intense step to take, and should be taken accordingly. It definitely works, but itâs a lot more things to get wrong.
I imagine a reasonable way to handle the kill switch is to disable internet on boot up, then manually enable after everything is up and running.
All VPN providers recommended by PG offer OpenVPN and/or Wireguard configuration files. With those, you can use any VPN software you want, for example the included one in Linux.
Or, even install OpenWrt and directly enable your router to use Wireguard.
RDP ?
If we are talking about LE, they could easily see that all your packets go to Server A, then just see all of YOUR activity from there. Whereas with a VPN, it will be much more difficult, as others will provide noise for you. Plus, in court, they will have to prove that it was you - not one of the other hundredth of users- that committed crime X.
Hi,
I was quite involved with this test so feel free to ask me questions and challenge our approach. The text of the tooltip adds to the confusion, weâll admit that. Weâll be looking at a way to rephrase it to reduce the confusion.
Our approach is:
- IP and DNS Leaks (box): Any data before the tunnel is established is not considered a leak in this context. However once connected everything should go through the tunnel and should be encrypted. API calls or DNS calls outside the tunnel are considered a fail.
- Kill Switch Robustness (box): Any data outside the tunnel is a leak. If the user is configuring the kill switch to block everything in case of a loss of internet then nothing should go through.
Yes it is very severe but our approach is that it would not be that hard for the client to cache the last server IP for a few hours and attempt to reconnect by IP only.
If the cache has expired or the IP cannot be reached, have the client visually let the user know that the kill switch is currently blocking traffic and the server cannot be reached. Itâs also possible to let the user know that in order to reconnect the kill switch will need to be bypassed once, ensure all the apps you do not want to leak are off and then once the button is pressed the calls to their service can proceed.
Overall we preferred to be more harsh and have users let us know we went too far than being too permissive and have users expose themselves because we said a VPN is leak proof.
4 Likes
I want to clarify, did you always use the VPN client strongest leak protection, for example the,
âLockdown modeâ for Mullvad or the âAdvanced Kill switchâ for Proton?
PS: I would appreciate if you could share the network logs directly, so we can see what the none locked network requests directly.
Yes, anytime a test fails, the testing team would look into what setting could make the test pass and as long as itâs not an obscure fix we would score based on that and in complex cases add a note. It is possible we have missed some but I remember clearly that we did retests on Mullvad, Proton and others to ensure we used every setting available to try to get it to pass. This included changing the protocol used (e.g: Hydra for Hotspot Shield).
For the logs, thatâs not impossible to do. Let me add it to our improvement suggestions. We do have the files saved so it can be retroactively added. I there is one in particular that you would like to see I can find a way to share it with you.
1 Like
The Wireshark logs of Proton and Mullvad.
I mean thanks for responding here (did you already knew this forum before?).
For sure noting each client settings is a must if your target is the VPN âexpertsâ.
I guess the question is why connections outside the tunnel that are only used to re-establish the tunnel are considered equivalent to connections to random third-parties like Microsoft, etc. in your testing.
Kill switches that are intelligently designed to provide an exception for this behavior arenât poorly designed, they are just designed differently from your proposal, which still seems like a valid choice to make. The connections donât expose users more than they already are, because the fact youâre using a VPN is always discoverable by your ISP.
2 Likes
Packet tracing is just the icing on the cake. The cake is an actual extraction of your physical device that you canât deny isnât yours.
By RDP I mean a remote windows server that you connect to via the remote desktop protocol. It will solve any paranoia about kill switches.