You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
Local network sharing does not allow my computer (10.0.0.2) to ping my phone (10.0.2.2) across subnets when the Mullvad desktop app is connected to Mullvad's server.
I am connected exclusively using WireGuard with Lockdown mode enabled. The two devices are on separate VLANs but have the appropriate firewall rules set up so that they may communicate with each other. My phone also has the Mullvad app connected, with Local network sharing enabled too. My phone is always connected, and I don't think this issue has anything to do with the Mullvad Android app or my phone using Mullvad.
I have another computer (10.0.0.3) which is NOT connected to Mullvad and does not have the app installed, which CAN ping my phone, and my phone can also ping that computer just fine.
When I disconnect my computer from Mullvad everything works as expected. I am able to ping my phone, and my phone can ping my computer. It's only when I am connected that I cannot reach my phone (or any other device that is not also on 10.0.0.0/24).
Expected Behavior
My computer should be able to continue to reach my phone when I am connected.
Steps to Reproduce
Have a primary machine on one subnet (e.g. 10.0.0.0/24) with the Mullvad app installed with the Local network sharing setting enabled.
Have a secondary machine on another subnet (e.g. 10.0.2.0/24). In my case, this is my phone.
While Mullvad is disconnected, ping the secondary machine. You should successfully receive a response from this machine.
Select Connect in the Mullvad app to connect the primary machine to Mullvad.
On the primary machine, attempt to ping the secondary machine.
You should not receive a response from the secondary machine.
Failure Logs
No response
Operating system version
Arch Linux
Mullvad VPN app version
2024.1
Additional Information
I believe this has been an issue for a long while (several years) and I only recently figured out that the desktop app is the cause.
Is it a bug?
I have checked if others have reported this already
Current Behavior
Local network sharing does not allow my computer (
10.0.0.2
) to ping my phone (10.0.2.2
) across subnets when the Mullvad desktop app is connected to Mullvad's server.I am connected exclusively using WireGuard with Lockdown mode enabled. The two devices are on separate VLANs but have the appropriate firewall rules set up so that they may communicate with each other. My phone also has the Mullvad app connected, with Local network sharing enabled too. My phone is always connected, and I don't think this issue has anything to do with the Mullvad Android app or my phone using Mullvad.
I have another computer (
10.0.0.3
) which is NOT connected to Mullvad and does not have the app installed, which CAN ping my phone, and my phone can also ping that computer just fine.When I disconnect my computer from Mullvad everything works as expected. I am able to ping my phone, and my phone can ping my computer. It's only when I am connected that I cannot reach my phone (or any other device that is not also on
10.0.0.0/24
).Expected Behavior
My computer should be able to continue to reach my phone when I am connected.
Steps to Reproduce
10.0.0.0/24
) with the Mullvad app installed with the Local network sharing setting enabled.e.g. 10.0.2.0/24
). In my case, this is my phone.Failure Logs
No response
Operating system version
Arch Linux
Mullvad VPN app version
2024.1
Additional Information
I believe this has been an issue for a long while (several years) and I only recently figured out that the desktop app is the cause.
#4289 and #5326 may be related, but I'm not sure.
The text was updated successfully, but these errors were encountered: