Skip to main content

Foundations of secure split tunneling

Features 

Congrats, you crossed the finish line of our split tunneling series! We wrap up with Part 5 and explain the key attributes that informed our secure design and invite you to build upon it.

The previous article on split tunneling looked at common mistakes in the design and implementation of existing solutions. When we set out to build our own, we wanted to make something better, something more secure. As we carefully reviewed the list of common issues, certain patterns started emerging.

Sorting apps into three groups

What we found is that many existing implementations fail to define and enforce a proper model. In our design, we use a model that sorts all apps into one of three groups: Excluded, Included, and Undecided. This is important because we can now define rules for each group to ensure that apps will behave securely.

The groups' rules are actually pretty simple. The strength in this system lies in the fact that groups have no overlap and that the Undecided group removes any race conditions and ambiguity.

“Excluded” group

  • New connections are forced outside the tunnel.
  • Existing connections inside the tunnel are blocked.
  • If there is no IPv6 on the LAN interface, all IPv6 for this app is blocked to prevent it from leaking inside the tunnel.
  • Group association is inherited by child processes.

“Included” group

  • New connections are forced inside the tunnel.
  • Existing connections outside the tunnel are blocked.

“Undecided” group

  • This group does not communicate freely on any network.
  • New connections are pended until the app is promoted to a different group.

Seeing the rules laid out, you can imagine how apps are able to move between groups without issues. An app always exists on either side of the tunnel, never both.

Why three groups?

The Undecided group addresses a very important concern. Typically what happens on Windows is that apps start in the Included group and are later moved to the Excluded group. The app is moved at some unspecified time in the future when the VPN is done classifying it. This works well for a lot of apps and applications and is usually pretty quick to happen. But there are no guarantees. Depending on how stars happen to align on a particular day (actually: CPU model, system load, Windows edition, and other factors) the VPN could be slow to react, and meanwhile the app (which is supposed to be excluded!) is sending and receiving data inside the tunnel.

The Mullvad app places all launching apps into the Undecided group. This prevents leaks and removes the uncertainty that otherwise exists when apps are starting up.

Take our solution and run with it!

We hope our design and implementation advances the state of art for split tunneling on Windows. All of the issues listed in the previous article on leaks are addressed either in the design or by using proactive coding. As usual, Mullvad’s split tunneling design is open source and we invite others to study our work and build upon it.

How do I use Mullvad’s split tunneling feature?

The feature is currently available on Windows, Android, and Linux versions of the Mullvad VPN app.

You can find the setting under Settings > Advanced > Split tunneling. Platform-specific details can be found in our split tunneling guide.

That’s it, folks!

Thanks for following our five-part series on split tunneling! If you missed the previous articles, we invite you to peruse them at your leisure:

  1. What is split tunneling?
  2. When is split tunneling useful?
  3. The limitations of split tunneling
  4. Can split tunneling be leaking traffic?
  5. Foundations of secure split tunneling (this article)

For the universal right to privacy,
Mullvad VPN