Open jm355 opened 5 months ago
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.
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
Is it a bug?
I have checked if others have reported this already
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:
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.
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
Failure Logs
Operating system version
Arch Linux
Mullvad VPN app version
2023.6
Additional Information
No response