Inverse split tunneling

[nalllen]

The recent beta release that added split tunneling to windows is great, but its sadly not perfect for my use case since trying to add almost everything to the splitt tunneling list basically becomes unsustainable.

so i would really like a inverse split tunneling feature that only routes selected programs or ip's and leave rest unaffected.

a use case for this could be when performance and latency is very important for the majority of programs and games you run.

This might go against mullvads philosophy regarding privacy, but i feel it would be a great option to have!

[pinkisemils]

You should be able to exclude Steam and have all games launched by Steam to be excluded. Same goes for specific shells. But we'll consider this feature too.

[catwithbanana]

I would also like to see this feature added. The Mullvad app doesn't pick up a lot of my app installs, and hunting down every game and professional program I need to exclude is a gargantuan task.

It would be a big boost to usability if I could choose to only tunnel a few crucial programs, like web browsers, while leaving everything else untouched.

[Inverness]

I would also like to voice my support for this if it will help.

I want the best performance and least latency for the majority of programs I use. There are only a handful that I'm concerned with securing with a VPN.

I'd suggest an option for each program in the split tunneling list as to whether or not it will travel through the VPN, and then an option for whether all programs that are not in the list will go through the VPN or not.

This would offer a good level of control for all kinds of users.

[faern]

We will likely not implement this on Windows at least. Because we have looked at what would be needed and it's more work than a simple negation of some firewall rules. All these rules are pretty critical to the security of the apps and any extra logic introduces new risks of having bugs causing leaks that could be critical. We don't feel like the current need for this is large enough to justify such a risk. After all, the app is privacy oriented and the intended use case is that it tunnels all your traffic.

Since we currently can't make DNS on Windows go outside the tunnel for an excluded process it would be strange to exclude most processes and only tunnel a few. Because the DNS requests for all excluded processes would still go in the tunnel. And that's likely not what you would expect/want as a user only tunneling a few applications. All the applications outside the tunnel will get DNS responses as if they were in the tunnel, which could affect their behavior and functionality.

[asdffdsazqqq]

what a bunch of nonsense. i have posted exactly how to that on windows, and it is trivial.
and the fact is, other vpn providers have done that for years.

i believe the real reason is that mullvad vpn is stagnant, having financial issues, cannot afford to add a feature that is simple to implement and most wanted by paying customers.

for example, for two weeks now, at https://mullvad.net/en/servers.
"We are currently experiencing issues with our DAITA servers, we are looking into this"

why two weeks and still no fix?

[Johnyknowhow]

That's a shame. Having a whitelist would be most useful as I only really want to use Mullvad for IP masking for my torrent clients. I tried setting up OpenVPN with Mullvad using route-nopull and trying to get only my torrent client to tunnel through, but I just couldn't get it to operate properly, through any combination of port forwarding with MV, running the SOCKS5 proxy or not, and changing my settings, some trackers just wouldn't connect, UDP seemed to be all jacked, I got overwhelmed and gave up. Tunneling through the Mullvad App seemed to work fine though (and was much simpler; i admit to my lack of experience), so I opted to just use it and whitelist every other program I could think of, although I know there's lots still that aren't in the list that I'd have to add and manually browse for their executables.

Even though you can't implement a way for excluded applications to route DNS information outside of the tunnel, I don't really mind if all of my DNS traffic goes through the VPN tunnel anyway, as I only am really using Mullvad servers in my own geographical location, since I only want my IP to be masked, I don't really want to show up as a different country.

It would be a nice-to-have, but if it's far too much trouble to implement, I suppose the wants of a select handful of us users aren't that high on the development docket haha

[jonpolak]

Will inverse split tunneling be implemented for LINUX?

I've tried to implement this with the namespace technique but have not managed to get it to work with Mullvad. If there is a way to do it manually, with the namespace trick, then that would be good enough for me, but would love to have formal validated instructions from Mullvad on how to do it properly ensuring that DNS goes to the right tunnel/gateway and everything stays nicely segregated.

I was able to do this (with openvpn) before systemd-resolved took over DNS in Ubuntu. Now it's quite difficult to figure out what that resolver is doing and I rely on dnsleaktest.com to tell me!

[cooky-cook]

This is a real shame since certain competitors offer much more flexible settings - whitelist/blacklist and separate DNS for direct/VPN connections. The (apparent) superiority and configuration flexibility is one of the reasons why I haven't switched to Mullvad yet.

Their VPN client is open source. Why cannot Mullvad offer such a flexible configuration - is it due to security (if their implementation is inherently insecure, I think this fact should be made known) or not enough resources allocated/not seeing this as an important feature?

[dnet890]

@cooky-cook That PIA tunneling feature seems quite overwhelming and I know Mullvad is good for simplicity and less cluttered. So, I hope they can make it more simple.

[mikamidd]

This is something I'd love to see implemented for Windows too eventually.
In addition to PIA, I believe ProtonVPN also has both normal and inverse split tunnel, their apps are open source too.

[Apposite245]

Chiming in for support of this feature. I really only use Mullvad for one or two programs so having to manually split tunnel everything as I install new programs is becoming a headache.

[UnknownProgrammer-ttu]

Adding another comment to the pool of people who want this feature.

[VoidCruzer]

Adding another for someone who would like to see this implemented. This is the biggest feature I miss from ProtonVPN that Mullvad doesn't have. The way it is setup now is quite an annoyance to go through and find every program and is almost impossible for some games and anti-cheat etc.

[trunkensailor]

For a linux implementation, vopono would be a good reference implementation as doing split tunneling this way can be very useful.

I for one would really like to see this on android, though. OpenVPN already supports this (you can switch between a white- and a blacklist for apps that should be connected to the VPN) and I don't think this would be hard to implement.

[dedors]

I like the mullvad app, but this feature missing just made me go back to the horrible openvpn solution.

[unkn4wn]

This feature is absolutely necessary because many origin games don't work while split tunneling even if you exclude the origin launcher + exe files manually. Maybe I am missing an important exe file which I need to exclude too but if we had an "inversed split tunnel" the problem would be solved easily.

[Retribution1337]

The UK has now made it law that all sites that can show adult content require you to send them your ID or banking details, making this feature the only potential solution to making the internet actually usable here. Having to whitelist every single program on my PC except for my browser and discord is simply not viable.

This is pretty much exactly what I'm using this for on my machine. Primarily used it on my media server for downloads but now that this is happening, spooled it up on my desktop to make sure firefox and discord go through it.

Inverse Split Tunneling would be great.

[Lifell]

I would also very much like this feature. Just dropping my hand on the pile I suppose.

We will likely not implement this on Windows at least. Because we have looked at what would be needed and it's more work than a simple negation of some firewall rules. All these rules are pretty critical to the security of the apps and any extra logic introduces new risks of having bugs causing leaks that could be critical. We don't feel like the current need for this is large enough to justify such a risk. After all, the app is privacy oriented and the intended use case is that it tunnels all your traffic.

Since we currently can't make DNS on Windows go outside the tunnel for an excluded process it would be strange to exclude most processes and only tunnel a few. Because the DNS requests for all excluded processes would still go in the tunnel. And that's likely not what you would expect/want as a user only tunneling a few applications. All the applications outside the tunnel will get DNS responses as if they were in the tunnel, which could affect their behavior and functionality.

Is this still the case considering it has been 4 years?

[LuminousToucan]

FYI if you're having issues with Steam, closing and relaunching Steam after toggling on Mullvad (with Steam excluded in split-tunnel config) makes it not use the VPN connection and unblocks downloads.

Parsec I've had 0 luck with.

+1 for the inverse split-tunnel idea. I imagine demand for a feature like this has spiked massively as of late. Can't speak to the technical limitations or implementation and it's a feature which inherently adds more insecurity, but the market of normies who want to only route Discord and a browser through a VPN shot up by about 50 million recently, and things don't look like they're getting better soon - just a thought.

[MulvadViking]

Backing this feature—Mullvad’s only needed for some apps, so not looking to manually setting up split.

[DAOWAce]

I see why the devs may be holding back

I think it's simply due to a philosophical reason instead of a technical one.

There is no reason why most other VPNs have had inverse split tunneling for over a decade, yet one of the highest rated VPNs that advertises itself as the most "secure and private" lacks an option that goes against their design philosophy.

Split tunneling was added, after all. Inverting it doesn't seem like any challenge. (not a dev)

I will repeat again for visibility: Certain programs (eg minecraft java, Microsoft UWP apps..) are completely incompatible with split tunneling for reasons unknown (to me). Only an inverse split tunnel (or all VPN traffic, which is bad for server hosting) will let them run correctly.

[Hasshu]

What does the current approach mean for things like VoLTE and Wi-Fi calling?

[NeurekaSoftware]

I'm a new Mullvad user, and this is the one thing that bothers me. I may switch providers because of this not being an option.

[JG606]

Chiming in to also say that this is disappointing. I've been very happy with Mullvad up until now, but there are certain applications such as Java applications that I need to be able to exclude from the VPN, and cannot. I would also be satisfied with an inverse split tunnelling mode that allowed me to select apps to include rather than exclude. As it stands, I'm forced to switch VPN provider which is sad.

[vjt4]

Yeah I just refunded because this program does not have this feature.

[asdffdsazqqq]

what a bunch of nonsense. i have posted exactly how to that on windows, and it is trivial.
and the fact is, other vpn providers have done that for years.

i believe the real reason is that mullvad vpn is stagnant, having financial issues, cannot afford to add a feature that is simple to implement and most wanted by paying customers.

for example, for two weeks now, at https://mullvad.net/en/servers.
"We are currently experiencing issues with our DAITA servers, we are looking into this"

why two weeks and still no fix?

[faern]

Hi everyone participating in this discussion. I'm sadly going to close this as not planned. But I will with this post also explain why we are not going to implement inverse split tunneling, so you understand the reasoning.

TLDR:

• We think it's a dangerous foot-gun for our customers, that can hurt their privacy and security.
• On a technical level this would have huge implications for the app.

To quote the original discussion starter:

This might go against mullvads philosophy regarding privacy, but i feel it would be a great option to have!

We understand that this feature would be really awesome for some! But yes, ultimately we have concluded that it does not align with our privacy and security goals, and introduce too much risk for our customers. We have brought it up internally multiple times, due to this discussion and other ways customers has requested this feature. But we have been very hesitant every time, and then it was forgotten again. We feel like it's more fair that we close this and explain why instead of just let it sit open for a few more years.

Is it technically hard to implement? Yes, it is not trivial. There is no single switch to flip in the code to make the current split tunneling feature work backwards. It's way more intricate than that. The entire app is written ground up with the design goal to securely absorb all network traffic. Implementing inverse split tunneling is by no means isolated to the code dealing with the current split tunneling feature. There are many layers of safety mechanisms incorporated to make sure the user's traffic does not leak. Making the app not capture traffic by default, and only capture some traffic, would invert this entire fundamental design. This would include large changes to how we manage the routing table, firewall rules, DNS settings and more. If we were to implement this we would risk introducing bugs that would put users that do want to capture all traffic at risk. If there are legitimate code paths where the users' traffic should go outside the tunnel, it is much easier to accidentally make users leak that should not leak, compared to if these code paths would not even exist.

Even if we were to implement inverse split tunneling without any bugs, we think this is a huge foot-gun for our customers. If there is a way to configure the app to leak all traffic by default, we suspect some users might unintentionally get into that state. And no, I do not mean that we would implement the feature with terrible UX, nor that we think our users are stupid. This could easily happen if for example a browser upgrade changes the browser footprint in such a way that the code identifying which apps should go in the tunnel fails to match the browser after the upgrade. Now the browser would suddenly leak outside the tunnel, when the user intended for it to go in the tunnel. It might take a very long time before the user notice this leak. This is simply not acceptable. Yes, this problem could already happen with our current split tunneling. But the important difference is that if this happens now, an excluded browser would suddenly communicate in the tunnel instead of outside it. This is most of the time a way less dangerous change than the opposite. Always fail closed, never fail open.

Our recommendation would be that users that only wish to tunnel certain traffic should instead use the vanilla WireGuard app, and set it up so that it only captures certain traffic. It's not perfect, and it misses out on a lot of the other features that our app has sadly, but it would be the only way if you really need to capture only a small subset of all traffic on your device.

We hope you understand our motivation. We want to focus on privacy and security. Thank you.

[devingDev]

If you wanna assume your customers are dumb and don't know what they're doing great!
I already switched so not anymore interested anyway
Have a great day

[JaxxArmstrong]

There we have it black on white. They won't implement this to many crucial feature that would simplify a lot of user's daily life and we are now forced to either fork the project and implement it ourselves or are delegated to use non-preferred VPN products from other vendors.

Note that this is NOT a technical implementation, but they don't want to rewrite part of their app. Why this is is up to everyone to ponder on, but laziness comes to mind. I understand they aren't making bank on their product, but this is totally unacceptable.

Another customer switching to a competing product.

[GRIFFiin]

Maybe you could implement it as a new branch?? Like only "expert" would know how branch works in github, and we could bug report anything

[faern]

I'm locking this conversation so that the official response does not get lost in the thread. I imagine a lot of customers who find this thread are interested in Mullvad's stance in this. I do not think further posts will be constructive anyway.