Mullvad blocks connection to IPv6 server on the same LAN as client

[jm355]

Is it a bug?

• [X] 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

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

Current Behavior

I have an IPv6 only server on my home network. For the sake of this ticket to avoid sharing my ip address, let's say my ISP has provided my router with a prefix of 2001:db8::/64, my server has a unique global unicast address of 2001:db8::1, and my laptop has address 2001:db8::2.

When I try to ping my server while at home connected to mullvad, I get the following:

PING my.domain (2001:db8::1) 56 data bytes
From 2001:db8::2 icmp_seq=1 Destination unreachable: Port unreachable
From 2001:db8::2 icmp_seq=2 Destination unreachable: Port unreachable

It works as expected when I am connected to mullvad on a different network.

I think the issue is that the routing table recognizes that they have the same prefix, and attempts to route via wlan0 rather than via wg-mullvad, and since the address is not fe80::/10 or fc00::/7, it gets blocked by mullvad thinking it's preventing a leak.

~ $ ip -6 route
2001:db8::/64 dev wlan0 proto ra metric 1024 expires 86394sec mtu 1500 hoplimit 64 pref medium
fc00:bbbb:bbbb:bb01::1 dev wg-mullvad proto static metric 1024 pref medium
fc00:bbbb:bbbb:bb01:5:a:84:feed dev wg-mullvad proto kernel metric 256 pref medium
fe80::/64 dev wlan0 proto kernel metric 256 pref medium
default via fe80::ca8:d00d:fade:7e57 dev wlan0 proto ra metric 1024 expires 594sec mtu 1500 hoplimit 64 pref medium

Expected Behavior

Mullvad should recognize that the address has the same prefix as the wlan0 route, count it as "Local network sharing", and not block it.

If Local network sharing is disabled, mullvad should route an address with the same prefix as wlan0 through the mullvad vpn connection

(and of course, same for eth0 or any other network interface)

edit: mullvad should route this traffic through the vpn like with any other traffic

Steps to Reproduce

1. Set up ipv6 only server on network
2. attempt to connect to server from separate device on the same network with the same ipv6 prefix while connected to mullvad vpn

Failure Logs

N/A (I think)

Operating system version

Arch Linux

Mullvad VPN app version

2023.6

Additional Information

No response

[faern]

Mullvad should recognize that the address has the same prefix as the wlan0 route, count it as "Local network sharing", and not block it.

This would allow attacks such as the LocalNet attack. If we trust the router to tell us what should go inside or outside the tunnel, a malicious router can make sensitive traffic go outside the tunnel.

Here is our blog response to the discovery of LocalNet and why we are not vulnerable to it: https://mullvad.net/en/blog/response-to-tunnelcrack-vulnerability-disclosure

If we implemented this as described in the issue, we would be vulnerable to LocalNet on IPv6. However, I do of course understand your use case and your desire to make this work. And you might not include an evil router in our own threat model.

If we were to implement this it would have to be as a separate setting, or sub-setting to local network sharing. Where we explicitly ask the user's consent to allow traffic to potentially non-local IPs but that appear to be local.

On a technical level this includes some challenges. Currently local network sharing just unblocks a hardcoded known list of must-be-local IP ranges. If we want to implement it as suggested in the issue description, then we would need to parse routing table etc to know the "local" IP subnet.

[jm355]

Ah good to know, I didn't even think about that. In that case, I think the ideal solution would be routing through the vpn. This is what happens on android, I don't run into this issue on android