According to their docs, Mullvad’s “kill switch” is “built in” and “enabled automatically”. Well thanks to a nice email from my ISP I’ve just found this is bad info. Apparently the daemon failed on my linux box some days ago (with the helpful error “Result: exit-code”), I haven’t had time to troubleshoot the issue yet but evidently if the daemon fails to start, their “kill switch” guarantees are off.
I see another post on the front page right now that seems to indicate the WIndows client (never used it) also sends your traffic in the clear until the utility launches at login. As for as I’m concerned, that is NOT a kill switch. A kill switch should be fail SAFE. I’ve learned my lesson that I’ll have to set up my own solution if I want something reliable; I hope this can help others to make well-informed decisions on what software to trust for their privacy.
I have the home page on my browser set to Connection check | Mullvad VPN so I will get alerted if it isn’t functioning properly. I too had a problem that caused it to stop working unexpectedly. I use the socks5 proxy in my browser as an extra kill-switch as well. Some stuff, like cryptocurrency nodes, can be set to bind to the wireguard interface too.
I keep meaning to look in to how to configure the Linux firewall rules to make a permanent kill-switch, but haven’t got round to it yet. Do you have any experience setting that up, or do you have any other solutions in mind?
From your comment, I gather that you have received a DMCA notice (or any other warning for copyright infringement), otherwise, I don’t see another reason why you would have received an email from your ISP in this context.
Now you’ll understand why many users come crying that they received a DMCA notice while they activated the Killswitch, the saying goes, do NOT rely on any VPN providers "kill switch".
The VPN Killswitch alone depends on the configuration of the operating system and the proper functioning of the application, it is not enough, and do not rely on it.
Have you reported this to Mullvad’s support? Please send a problem report from within the app and explain your problem to them! If the daemon crashed and/or failed to start on boot then it’s an issue they would like to have fixed!
The daemon/kill switch is designed in such a way that if it crashes unexpectedly then it should keep your internet blocked. Because firewall rules are kept in place. However, if the daemon fails to start on boot even then it has no way of inserting protective firewall rules. This can’t be solved in a very clean way. The daemon must start. I don’t know why it did not start, but it should be fixed. Please give Mullvad the info you have so they can improve it.
There is one more case where the kill switch can fail on Linux. And that’s when you upgrade your kernel or nftables. This reloads the firewall and most Linux distros is set up so firewall rules are flushed on firewall service reload. mullvad-daemon currently does not detect this and does not re-apply its rules. It would be possible but really ugly to fix this. IMO the issue is that distros are configured to flush firewall rules on upgrades while they are still running!
I wonder if people confuse the built-in “kill switch” (which isn’t fully described what it does. It’s just acknowledged as existing) with the advanced “always require” option?
It sounds to me like you got hit by the computer having network connectivity without the secure tunnel connected (either the mullvad program wasn’t started, or the connection wasn’t created yet)? If that’s the case, then the “Always require” advanced option would protect you.
From what I gather, the so-called (and largely undocumented) “built-in kill switch” is just some kind of health test of the encrypted tunnel. Like a heartbeat or status from the server about the conditions being verified. (I don’t know what could go wrong. The server disappears?). Mullvad doesn’t describe this, as far as I’ve seen. They just allude to there being a mechanism that shuts down the tunnel if anything goes wrong with the tunnel.
If I’m right, that only protects you while the tunnel exists. If the program fails for some reason, the tunnel disappears, then you’re sitting at a computer with full clearnet access. If the app isn’t bound to the interface “tun0” it would talk to the clearnet. (That’s what the advanced “always require” is for. It blocks all traffic when the tunnel isn’t present. There are also options to automatically start Mullvad & connect.).
I think Mullvad should rename the “always require” option to “Full Kill Switch” (and note with hover text that there is a built-in tunnel-level “kill switch.” The optional “full kill switch” provides more protection for when no tunnel exists. If you wish to use your computer without a secure tunnel, you’ll have to disable this option.).
I bet most people think “kill switch” protects them from anything going wrong, and don’t realize it’s only in effect when there is a secure connection. When there isn’t, then Mullvad has no responsibility if an app talks to the available clearnet. I think the only responsibility they have is to clarify/distinguish these modes better as “connection-level” kill switch, and “machine-level” kill switch. It’s not clear to people what’s happening. (Plus, Mullvad doesn’t explain the connection-level, built-in “kill switch.” We take it on faith that it does everything you’d expect. We don’t know. But, clearly they put some of the (machine level) power in that “always require” option (which doesn’t stand out as a kill switch, but is IMO.).
I feel your pain OP, that’s why I modified the way the daemon works. It’s a .service and thus can be made to “auto start” on failure. So if the system is down it will start itself back up. Or you could set a cron/systemd-timer to check on it periodically. Can’t say what happened in your case exactly, but make sure there are fail safe points prior. (Add rules to have it start after login, the daemon that is. Unless you’re headless)
Have both kill switch & lockdown mode active on my Linux machine. I walk away from machine, return a few minutes later & find mullvad icon inactive. I have to manually re-enable VPN. BUT INTERNET IS ACTIVE ON MY MACHINE! I’ve reached out to support but got no answer other than to send logs. Mullvad used to be the only VPN I’d use or recommend. But now, even with lockdown mode activated, internet traffic is coming through on my machine despite app disconnecting. And it happens regularly. Very dangerous.
I see another post on the front page right now that seems to indicate the WIndows client (never used it) also sends your traffic in the clear until the utility launches at login
This depends on your settings! You have to enable either Launch app on start-up + Auto-connect OR you have to enable Always require VPN in the app for it to block internet directly on boot.
It’s the same on all platforms and it’s by design. The daemon does not block your internet on boot simply by being installed. You have to enable the settings that makes it engage on boot.
I don’t use the VPN on my workstation so this wouldn’t be applicable to me, but I’d advise you against relying on it too- all it takes is one packet sent in the clear to get slapped with a DMCA notice, you’re certainly not going to notice and correct the problem in time this way if you’re actively torrenting (for example - maybe you have a different use-case and this isn’t applicable).
What you need to do (if this is a DMCA notice) is to bind the VPN traffic to the network interface of your Bittorrent client, qBittorrent is probably the best for this, it has advanced security features that other clients lack, so, you will have a killswitch that works by design, and no longer on the proper functioning of an app.
I don’t know what possible interpretation of a VPN kill switch there could be other than “a feature that prevents leaks from happening”. If it’s technically infeasible for them to provide that (it’s not, though doing so on all supported platforms would admittedly be a significant support burden), they should simply not advertise that feature. Direct customers to use appropriate tools on their system to implement it themselves.
? It was running fine on this box for many months - my assumption, which I don’t think was unreasonable, was that a client which advertises a “kill switch” feature would kill the connection in the case of a crash, so I didn’t think it necessary to set up any additional safeguards or alerting on the service. As I said, obviously I’ve learned my lesson.