Windows Sandbox Leaks

[issuant]

Is it a bug?

• I know this is an issue with the app, and contacting Mullvad support is not relevant.

I have checked if others have reported this already

• I have checked the issue tracker to see if others have reported similar issues.

Current Behavior

This is on the Releases page

Block WSL/Hyper-V traffic in secured states (except the connected state). The normal firewall (WFP) filters normally do not apply for VMs. This mitigates the issue by ensuring that it does not leak (as easily) when the VPN tunnel is up. Previously, WSL would leak while in the blocked or connecting state, or while lockdown mode was active.

Is this saying Windows Sandbox leaks the user's real IP address? To what or whom is it leaking?

Expected Behavior

n/a

Steps to Reproduce

n/a

Failure Logs

No response

Operating system version

Windows 10/11

Mullvad VPN app version

No response

Additional Information

No response

[VPNPrivacy922]

Does this mean that while lockdown mode was enabled and I was connected to the VPN the real IP was leaking inside the VM? Or does this mean that the real IP leaked while VPN tried to connect? Both cases are really bad!

[issuant]

I would like to know that too.

[Serock3]

Hello!

We are overdue an update to the original blog post detailing the issue, but here's the (not so) short version.

We define a leak as "the possibility of traffic being sent outside the tunnel", as an outside observer could observe your real IP and e.g. the websites you are visiting. The Mullvad VPN client has two layers of protection against leaks:

1. Network routes that instructs applications to send their data into the VPN tunnel
2. Firewall rules that drops traffic going outside the tunnel

The second layer is needed as applications can choose to ignore the routing table and send their traffic to the physical interface directly, though this not very common. It is also used when the tunnel goes down unexpectedly and you enter the blocked state. For example, if your account runs out of time you will get disconnected from the relay. In these cases we enter the "blocked state" where all traffic is stopped to prevent leaks as the tunnel and its routes are gone.

The issue with virtual machines

Windows has a native hypervisor for managing virtual machines, called Hyper-V, which handles both WSL and Windows Sandbox. Traffic from such virtual machines ignores normal firewall rules from Windows Filtering Platform (WFP). This means that, before version 2024.9 of the app, the second layer of protection has not been functioning for traffic to and from virtual machines on Windows. While you were connected, your traffic would most likely still be routed inside the tunnel. However, while you were connecting (or switching location) and while you were in the blocked state, all traffic would leak outside the tunnel.

What's fixed in version 2024.9

Since we detailed the original issue in 2020, Microsoft has introduced a limited firewall for Hyper-V traffic. Using it, we have implemented rules for blocking all traffic from virtual machines during the "blocked" and "connecting" states. This means that, if e.g. you account runs out of time, or you disconnect with "lockdown mode" enabled, all traffic should be blocked to prevent leaking your IP address. We do not, however, have the ability to filter out traffic headed outside the tunnel while connected, so you are still vulnerable to malicious applications that ignore the routing table.

Special note on Windows Sandbox

Unfortunately, it seems that the new firewall rules are not working as intended for Windows Sandbox. The feature was mainly tested using WSL, but after some further investigation it seems like the new firewall rules aren't properly filtering all traffic from Windows Sandbox. We will look into this further.

[issuant]

@Serock3 That sounds really bad and I wish I knew this beforehand. Is it normal that visiting mullvad.net/en/check from within and outside Windows Sandbox did not indicate there was an issue?

However, while you were connecting (or switching location) and while you were in the blocked state, all traffic would leak outside the tunnel.

Where is this leak occurring? Within Windows Sandbox or the main desktop? Both?
To what is it leaking? Applications within Windows Sandbox or the main desktop? Both?

Does this leak still happen if Mullvad is installed only in and used from the main desktop, not Windows Sandbox?

[Serock3]

Good questions.

What/where is the leak occurring

Only applications from within the virtual machine can leak, the host OS (your desktop environment) is safe.

To what is it leaking?

It wouldn't leak to anywhere in particular. Rather, as the traffic would go outside the tunnel, anyone who could intercept your traffic, e.g. your ISP, could see your IP address and what you are browsing.

Is it normal that visiting mullvad.net/en/check from within and outside Windows Sandbox did not indicate there was an issue?

If visiting mullvad.net/en/check in Windows sandbox does not indicate a leak, then you probably aren't leaking. As I mentioned, while you are connected then the routing table should still correctly make sure your data is sent in the tunnel. Certain programs have been known to ignore the routing table, and would therefore send the data unencrypted. They are fortunately few and far between, and you browser evidently isn't one of them. However, if you lose your connection and end up in the "blocked state" for whatever reason, the data would start leaking.

Does this leak still happen if Mullvad is installed only in and used from the main desktop, not Windows Sandbox?

Yes! This only happens if the app is installed in the host OS. If you install Mullvad VPN in Windows sandbox (or WSL) itself, it will work normally 🙂

[issuant]

However, if you lose your connection and end up in the "blocked state" for whatever reason, the data would start leaking.

Does this also apply with toggling 'Local network sharing'? I ask because there is no internet connection, or at least there appears to not be any, if that is not toggled on in Mullvad's setting.

[Serock3]

I have done some limited testing which I can share, but Windows Sandbox seems to behave strangely and I can't guarantee that it will work the same for you. From my testing it seems that while most traffic from Windows Sandbox ignores all our firewall rules, but DNS is sent to a local resolver which is for some reason caught by our non-Hyper-V filters. This causes DNS to be blocked unless local network sharing is on.

Does this also apply with toggling 'Local network sharing'? I ask because there is no internet connection, or at least there appears to not be any, if that is not toggled on in Mullvad's setting.

If I understand your question correctly, you are asking whether data leaks while in the "blocked state" when local network sharing is disabled. The answer is yes, DNS traffic will be blocked but other traffic will leak outside the tunnel, which you can verify by pinging some address from within the Sandbox, e.g. by running ping 1.1.1.1 in Powershell. If your question is whether traffic will leak when connected with local network sharing enabled, then the answer is no. Both DNS and non-DNS traffic seems to be correctly routed to the tunnel interface. Though as I mentioned earlier, there is no firewall to block apps from leaking to the physical interface if they disregard the routing table.

[issuant]

If I understand your question correctly, you are asking whether data leaks while in the "blocked state" when local network sharing is disabled. The answer is yes, DNS traffic will be blocked but other traffic will leak outside the tunnel, which you can verify by pinging some address from within the Sandbox, e.g. by running ping 1.1.1.1 in Powershell.

Sorry if this is redundant but since it might change the answer, I have to ask, is this happening if I have Mullvad installed only in the main desktop and local network sharing is turned off? That is surprising because before turning that on, Windows Sandbox reports there is no internet connection.

[Serock3]

I suspect that what you experience as not having access to internet inside Windows Sandbox is actually just DNS being blocked. When DNS is blocked you cannot access websites by their domain name, but you could still send traffic to an explicit IP address. As I mentioned, you could try this by running ping 1.1.1.1 in a Powershell terminal from within the Sandbox. If the pings go through successfully, then you can access the internet.

After looking in to it some more and discussing it with the team, we have concluded that it is most likely not possible to filter traffic from Windows Sandbox. It doesn't expose a VMCreatorId, so there is no way to apply rules targeting it. For now, we must consider this to be a fundamental limitation of the app. My suggestion is that you just install the VPN app inside Windows Sandbox itself. You can run an instance of the app on the host OS as well, if you want, they shouldn't conflict.

[issuant]

This is all a very unfortunate and terrible error by Microsoft.

so there is no way to apply rules targeting it. For now, we must consider this to be a fundamental limitation of the app

It is not foolproof since someone can launch the Sandbox before toggling it but would it worth having a notification pop up when turning on local network sharing warning about these leaks?

[Serock3]

would it worth having a notification pop up when turning on local network sharing warning about these leaks?

That local network sharing is needed for DNS in to work in Windows Sandbox isn't really related to the leak, per se.

We have added a section about the Windows Sandbox leaks to our known issues document. I know it's not foolproof, but I hope that affected users can find information about the problem there or in this thread. I'll close this issue as "not planned" to indicate that the leaks remain.

It's unfortunate that we couldn't find a proper fix, but thanks for reporting the bug and helping to spread awareness!

[issuant]

That local network sharing is needed for DNS in to work in Windows Sandbox isn't really related to the leak, per se.

Yes, that is correct. That is why I suggest having it there since interacting with it is a requirement to get things to work.