Open AwlsomeAlex opened 1 year ago
Same on Debian with virtualbox.
Thanks for reporting. We have created an internal ticket for this. For the Linux VM under macOS Virtualization.Framework specifically. I don't think it's the same issue stopping this from working on Debian + virtualbox. Those are almost definitely unrelated bugs.
@faern I will note, enabling "Local Network Sharing" fixes the issue for Parallels, but not for UTM. I believe they use different IP ranges. My "Shared Network" guest looks to be using 192.168.64.x in UTM if that helps.
I realize the issue does not state if Mullvad is running on the macOS host, or the Linux guest VM. That would be crucial to know. I have assumed it runs on the macOS host.
Can the host reach the VM and vice versa? Is the VM completely blocked out from the virtual network it's connected to, or is it just forwarded internet traffic that is blocked? Can you try pinging both ways?
On my side, it’s when mullvad is running on the host (debian) and there is a vm on virtualbox (no matter the os).Le 30 nov. 2023 à 12:12, Linus Färnstrand @.***> a écrit : I realize the issue does not state if Mullvad is running on the macOS host, or the Linux guest VM. That would be crucial to know. I have assumed it runs on the macOS host. Can the host reach the VM and vice versa? Is the VM completely blocked out from the virtual network it's connected to, or is it just forwarded internet traffic that is blocked? Can you try pinging both ways?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>
Also having this issue.
Host OS: Sonoma 14.2.1 on M1 Pro Mullvad on host: 2023.6
VM: UTM 4.4.5 GuestOS: Fresh Win11 arm64 install
Guest OS can resolve DNS but not make any connections.
Mullvad enabled:
Pinging google.com [142.251.35.174] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 142.251.35.174:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
Mullvad disabled:
Pinging google.com [142.251.35.174] with 32 bytes of data:
Reply from 142.251.35.174: bytes=32 time=25ms TTL=113
Reply from 142.251.35.174: bytes=32 time=26ms TTL=113
Reply from 142.251.35.174: bytes=32 time=26ms TTL=113
Reply from 142.251.35.174: bytes=32 time=40ms TTL=113
Ping statistics for 142.251.35.174:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 25ms, Maximum = 40ms, Average = 29ms
Does not matter whether Local Network Sharing
is enabled or not.
On the other hand, enabling a VPN with the wireguard.com App version 1.0.16 works just fine allows ping but no web traffic.
Found a sufficient workaround (kudos to Mullvad support). Changing QEMU network mode for the VM from the default Shared Network
to Emulated VLAN
(did not change any other setting) was enough to allow the guest to access Internet hosts. Traffic is routing correctly via the VPN.
Yeah, VMs is hard! Because it depends on how the hypervisor implements networking. Mullvad only looks at and cares abount Layer 3 traffic (IP). If the VM networking is done on Layer 2 (Ethernet) it becomes transparent to our app's firewall rules and can cause various problems.
Are there any updates on this issue? I have stumbled upon this problem and no matter which network mode I select (apart from Bridged) MullvadVPN blocks the connection. Only way I can use VMs with MullvadVPN installed is by disabling it which is not ideal...
Issue report
Operating system: macOS Sonoma (14.0.0 - 23A344); Apple Silicon
App version: 2023.5-beta2
Issue description
Tried to connect to internet on Virtualization.Framework Linux VM. Connection wouldn't establish until Mullvad was disconnected. Works fine in Parallels. Tried with two different Virtualization.Framework clients (UTM and VirtualBuddy) with same result. Same result with UTM in QEMU mode as well.