Can split tunneling be leaking traffic?
As we near the end of our split tunneling series, we look under the hood in Part 4 to examine where leaks tend to occur in split tunneling solutions.
When using a VPN, a traffic leak occurs when data is sent on the wrong side of the tunnel, or more specifically outside of it. With split tunneling, the “wrong side” becomes interesting. If an app has been excluded from the tunnel, leaking would occur if its traffic is sent inside the VPN tunnel.
Where leaks occur – examples in Windows
While in the process of designing our own split tunneling implementation, we examined other VPN solutions and noticed that leaks typically occur at certain points. Let’s take a closer look at those points, narrowing our focus specifically to Windows implementations of split tunneling.
Windows is especially interesting, both because it's widely used and because the system has built-in support for traffic splitting. However, the built-in support doesn't address leaks in the slightest, and therefore it's entirely up to the VPN provider to stop leaks from occurring.
Changing a running app from included to excluded
If a running app is dynamically updated to become excluded and existing in-tunnel connections are allowed to remain functional, the app now exists on both sides of the tunnel. When you enter data into the app, there are no guarantees as to which side of the tunnel communications will be sent on.
Changing a running app from excluded to included
This is just like the scenario above, except the running app is updated to become included.
If a child process of an excluded app is not automatically excluded
We have to assume that any child processes share a context with their parent, because they could be. By not excluding the child, the context now exists on both sides of the tunnel. See the first point for why this is bad.
Through a race condition that may exist before a launching app has been evaluated for splitting
In a naive implementation of split tunneling, running apps are divided into two categories: excluded apps and all others. However, if an app starting up is by default in the second category, and is later promoted to the first category, there is always going to be a short moment of time during which it can communicate freely inside the tunnel.
If IPv6 is not supported in the splitting logic
Default networking logic will send the excluded app's IPv6 traffic inside the tunnel, making the app exist on both sides of the tunnel.
If connections to localhost are mistakenly considered in the splitting logic
This is a simple coding bug which is easy to avoid. In unfortunate cases, this can result in private services or daemons being accessible on the local network.
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.
Up next
This article is in a five-part series on split tunneling – all written by a Mullvad developer. Stay tuned for the final installment which will discuss the foundations of secure split tunneling.
If you missed the previous articles, we invite you to peruse them at your leisure:
- What is split tunneling?
- When is split tunneling useful?
- The limitations of split tunneling
- Can split tunneling be leaking traffic? (this article)
- Foundations of secure split tunneling
For the universal right to privacy,
Mullvad VPN