Always on kill switch.

[InJustIs]

I've been trying out Mullvad, and I noticed the client doesn't have a reliable always on kill switch. By always on, I mean should the mullvad service be stopped or the client crashes my connection should get disconnected but it doesn't.

The role of the always on kill switch is to essentially prevent all communication unless connected to a VPN regardless if the client is open or not. Some of the other VPN clients provide this function and it would be nice to see it implemented. The current kill switch implementation basically only prevents leaks during momentary disruptions. I'm not sure I can confidently rely on this type of implementation for regular use.

[faern]

Which version of the app are you running? We have always active protection that you are supposed to be able to rely on, but maybe we have not communicated well how it works. We do have a system service running in the background that should protect you at all times. But if you quit the GUI frontend app or click disconnect then of course we disconnect the VPN tunnel and let your internet traffic out the normal way.

[faern]

We have in the backlog to implement so that quitting the GUI does not disconnect the VPN tunnel. When that is implemented, and if you activate this setting. Then you can be sure that no matter if you start or stop the GUI, log in and out of your user account or whatnot, you will still be protected. Until you explicitly tell it to disconnect with the disconnect button.

[InJustIs]

I'm on the stable version (2018.3). My concern isn't really regarding disconnecting or quitting the GUI, but rather it crashing for whatever reason. I use a lot of programs, many of them are for monitoring system components, and even if there is a 1% chance of them causing the GUI to crash I'd rather have the option for the kill switch to disconnect all connections.

As it is now if you "emulate" that by using task manager to stop the service or end the task, my connections don't stop.

[faern]

I'm not sure exactly what it is that you want. If the GUI crashes (either by accident or you killing it) do you want the VPN tunnel to stay up or to disconnect? Currently if you kill the GUI without giving it any chance to clean up after itself the system service will keep the tunnel up and running and keep your computer protected. It does not kill any connections, but it also does not leak anything outside the tunnel. On the other hand, if the GUI quits more gracefully then it will instruct the system service to disconnect while it's exiting. This will cause the system service to disconnect the VPN tunnel and let traffic out on the internet without any tunnels.

What I guess you want is the option I described earlier. That changes so the GUI never instructs the system service to disconnect while it's exiting/dying. This way the VPN tunnel will remain active, and the computer protected from leaks, no matter in what way the GUI dies/exits.

[InJustIs]

Yes, that would be one implementation of it. The other would be to have it disconnect my connection entirely until the service is restarted.

The ideal implementation would be the latter, where if I switch on the always on kill switch, then my PC is prevented from accessing the internet outside of the Mullvad connection, regardless of whether or not I disconnect manually or not. In a sense it's acting like a firewall rather than a "kill switch"

I can give an example of another client that has this feature and you can test it out, but not sure if you want me to discuss another competitor's product in this setting.

[pronebird]

Basically we would have to block the internet communication in disconnected state, just like we do when connecting the tunnel or experiencing some issues. (aka blocked state) So if tunnel is being disconnected, even by user, the network should remain blocked. I am pretty sure we had a kill switch feature somewhere in our backlog.

Speaking of reliability as @faern already pointed out, we run the tunnel management as a separate service process. The operating system makes sure it’s always on, even if you forcefully quit it, it will be restarted.

Currently we don’t implement the kill switch but if we did, stopping the service would make sure that the connection is blocked at least until the service is restarted.

[InJustIs]

Basically we would have to always block the internet communication, just like we do when connecting the tunnel or experiencing some issues. (aka blocked state) So if tunnel disconnects even by user, the network remains blocked.

Yes exactly, sorry if I wasn't articulating that properly.

Speaking of reliability as @faern already pointed out, we run the tunnel management as a separate service process. The operating system makes sure it’s always on, even if you forcefully quit it, it will be restarted.

I understand; however, the permanent kill switch would act as a fail safe in the event that all the stars align and the service is somehow shutdown without the user's knowledge. If you're telling me with your current system there is no possible way for a momentary lapse in the VPN service to result in a IP leak then fair enough, I suppose I just wanted the peace of mind.

[pronebird]

I understand; however, the permanent kill switch would act as a fail safe in the event that all the stars align and the service is somehow shutdown without the user's knowledge. If you're telling me with your current system there is no possible way for a momentary lapse in the VPN service to result in a IP leak then fair enough, I suppose I just wanted the peace of mind.

That makes sense. Thanks for bringing this to our attention. We'll discuss that with the team and keep you posted 👍

[pronebird]

@InJustIs there's been a discussion around the office here and I figured that I have to correct my recent statement, that folks outside of our message exchange thought was incorrect.

Basically we do implement a kill switch as long as you initiate the connection in our app, either by selecting a certain location or specific server, or by hitting a "connect" button for preselected one.

But we don't implement, let's call it "a permanent kill switch", that blocks the communication if the service is going down for some reason (which normally should not happen). Disengaging the service by hitting the "disconnect" button always clears out all the firewall rules, so the traffic can flow freely too.

[InJustIs]

@InJustIs there's been a discussion around the office here and I figured that I have to correct my recent statement, that folks outside of our message exchange thought was incorrect.

Basically we do implement a kill switch as long as you initiate the connection in our app, either by selecting a certain location or specific server, or by hitting a "connect" button for preselected one.

Yes I'm aware of this kill switch. (Unless you posted this for future readers who may not be aware)

But we don't implement, let's call it "a permanent kill switch", that blocks the communication if the service is going down for some reason (which normally should not happen). Disengaging the service by hitting the "disconnect" button always clears out all the firewall rules, so the traffic can flow freely too.

Yes, it's this implementation that I'm looking for. Here's a little description of the feature in another VPN program:

"When this option is enabled the Firewall is started during Windows boot time before any other process. The Firewall will always be active even when the client is not running"

Of course this feature is also available in a variety of other programs with different names but they all work similarly.

[faern]

"When this option is enabled the Firewall is started during Windows boot time before any other process. The Firewall will always be active even when the client is not running"

We have this exact same feature as well. Only difference is that we explicitly unlock the firewall if the GUI app is exited, or disconnect is clicked. So for people who instead of choosing between Mullvad or regular internet want to choose between Mullvad and no internet, we can add a separate setting that on disconnect simply does not unlock the firewall. Then we'll have the thing you want. We will look into this.

[ghost]

This feature request comes straight from the IVPN client that gives the user the ability to set an always-on firewall killswitch - even if the user disconnects from the IVPN server, exits the IVPN client or the service crashes. Except for a tiny minority of users, no one is going to disconnect from the VPN to invoke the always-on killswitch so that they can use their system in off-line mode.

In theory it is fine, but in practical terms the usability isn't the greatest because if one decides to disconnect from the VPN, then they also have to disable the always-on killswitch setting if they want to use their ISP network.

The Mullvad implementation seems practical to me. The killswitch is always on until the user disconnects from the Mullvad network or exits the client. When exited the user has convenient access to their ISP network. If I am not mistaken, the Mullvad killswitch is functional during system boot if the user configures the client to auto-run and auto-connect (please correct me if I'm wrong here). Finally, the Mullvad killswitch kicks-in immediately if the connection fails - which is really the purpose of both the Mullvad and IVPN killswitches.

I suppose the reason IVPN implemented this network lock-down via the always-on killswitch was some study that said there was some kind of observable (but not necessarily a risk) data leak either when the user disconnected from the client or the service stopped.

So, in short, if you want to see what the OP is talking about, then just grab the IVPN client and service. The snippet that was quoted here is cut-paste directly from their website if I recall correctly.

[faern]

We have implemented this now and it's available in the latest source code. But no releases with this feature yet. If you don't want to build from source then wait for the next beta/stable to get this feature exposed in the CLI (not in the GUI yet)

[InJustIs]

We have implemented this now and it's available in the latest source code. But no releases with this feature yet. If you don't want to build from source then wait for the next beta/stable to get this feature exposed in the CLI (not in the GUI yet)

Great! Thanks a lot. I'll keep an eye out for the release.

[faern]

This is now available in our new beta release. It's still only exposed via the CLI though. If it turns out to work well and there is demand, we will add the setting to the GUI. The beta is available here:

https://github.com/mullvad/mullvadvpn-app/releases/tag/2018.6-beta1

And the way to activate it with the CLI is:

mullvad block-when-disconnected set on

[tmp332]

How about this situation, which happened to me recently: macOS automatically updated and restarted while the computer was not being actively used but was running with the display turned off. On restart as best I can remember Mullvad (the GUI) was no longer running, though other apps had been relaunched.

1. Do you think that the connection was still going through the VPN tunnel?
2. If not, would this be solved by enabling "Launch app on start-up" and "Auto-connect"?
3. Does the killswitch ("Always require VPN" setting) discussed above have any bearing on this situation?

Thanks.

[faern]

In your case enabling "Launch app on start-up" and "Auto-connect" should have solved the issue. Those two together informs the Mullvad system service (mullvad-daemon) to secure the system as early as possible during boot and establish a tunnel again as the computer comes online.

Yes, enabling "Always require VPN" would also stop any leaks after boot. But if that setting is active and "Launch app on start-up" and "Auto-connect" are not active then all it does is to block all network connectivity until you manually start the GUI and connect the tunnel again.

So it depends on if you want a tunnel set up automatically after a reboot or if you want everything to be blocked until you manually start things again.