Bug: Kill switch applies to non-global unicast IPv6 ranges

[neilalexander]

The kill switch built into the Mullvad app to prevent traffic leaks should not apply to IPv6 ranges outside of the 2000::/3 global unicast range.

Otherwise it becomes impossible to contact non-global unicast networks such as local ULA ranges (fc00::/7) or Yggdrasil Network (0200::/7) while Mullvad is running.

[pinkisemils]

We're currently considering having a more granular setting for allowing various traffic. It's difficult to know the privacy implications for each IP range that is allowed, and IPv6 mishaps/misrouting is not uncommon, especially for ISP issued routers, thus I hope you'll appreciate our stance on being eager to block traffic.

[neilalexander]

Thanks for the response. I think the salient point here is that Mullvad provides a route to the internet and the IPv6 internet lives definitively within 2000::/3. It really is not the job of Mullvad to interfere with traffic towards private networks — more often than not you'll break users instead of help them.

What you are doing today is practically equivalent to dropping traffic to 192.168.0.0/16 or 10.0.0.0/8 and leaving me to wonder why I can no longer reach my wireless speakers or printer at home anymore.

[faern]

Otherwise it becomes impossible to contact non-global unicast networks such as local ULA ranges (fc00::/7) or Yggdrasil Network (0200::/7) while Mullvad is running.

We already allow fc00::/7 if you enable local network sharing in our app. Check out our security documentation: https://github.com/mullvad/mullvadvpn-app/blob/master/docs/security.md#app-states

I think the salient point here is that Mullvad provides a route to the internet

We are responsible for much more than that. We are responsible for making sure the user is not leaking traffic in any way that can deanonymize them or be bad for their privacy.

What you are doing today is practically equivalent to dropping traffic to 192.168.0.0/16 or 10.0.0.0/8 and leaving me to wonder why I can no longer reach my wireless speakers or printer at home anymore.

By default, yes. But there is a setting to allow this traffic, as outlined above.

This issue is highly related to #3870

[L-as]

@faern I've done mullvad lan set allow ; mullvad always-require-vpn set off and Yggdrasil still doesn't work, so it's blocking it somehow. What setting am I missing to make this work?

[faern]

I don't know. I have never used Yggdrasil. I don't know what routes/firewall rules etc it adds to the system. But if it does not work it's likely that there is some incompatibility in the system settings injected by us and them.

[neilalexander]

I don't know what routes/firewall rules etc it adds to the system.

For clarity, we don't modify the firewall or inject anything. All Yggdrasil does is create a TUN adapter with a 200::/7 interface address.

[faern]

The address block 200::/7 was defined as an OSI NSAP-mapped prefix set in August 1996,[52][53] but was deprecated in December 2004.[54]

Doesn't sound like a very valid range to me. Our allow LAN settings unlocks IP ranges that are known to be local only/not globally routable. We do allowlisting, not blocklisting because it's safer.

What you are doing today is practically equivalent to dropping traffic to 192.168.0.0/16 or 10.0.0.0/8 and leaving me to wonder why I can no longer reach my wireless speakers or printer at home anymore.

No, we allow all sane ranges that are defined as not globally routable, but block the rest. My interpretation of 200::/7 is that it should not be used. So it's not on our allowlist.

But you can just work around this yourself by adding custom firewall rules with higher priority. You can take some inspiration at https://mullvad.net/en/help/split-tunneling-with-linux-advanced/