After upgrading from Parallels Desktop 20.1.0 to 20.3.0 on macOS Sequoia 15.4.1 (Apple Silicon), I've encountered a regression that affects connectivity to VMs using Shared Network mode. ❗️Problem Summary My VM (Ubuntu 22.04) receives an IP in the 10.211.55.0/24 subnet via bridge100 as expected. From the host system (macOS), I cannot connect to the VM's IP unless the client is run as root. Any unprivileged TCP client (nc, ssh, curl, etc.) fails with: "connect to 10.211.55.64 port 22 failed: No route to host" The same command works perfectly with sudo. This is also true for ping (only works with sudo) Diagnostic Details Routing and interface configuration on the host are valid (netstat, ifconfig confirmed). Packet captures (tcpdump) show no outgoing traffic at all from unprivileged clients -- confirming that the OS is blocking the socket call itself, not the network. The issue does not occur in Parallels 20.1.0, and seems to began after upgrading to 20.3.0. ⚙️ Environment Details macOS Sequoia 15.4.1 MacBook Pro 14", 2021 - Apple M1 Max Parallels Desktop 20.3.0 VM: Ubuntu 22.04, using Shared Network mode Bridged and public network modes not yet tested Key Release Note in 20.3.0 "Improves the Shared network mode for macOS virtual machines running on Apple silicon Macs, enabling them to remain on the same VPN connection as your Mac's own macOS system." ❓Questions Is this a known side effect of the Shared Network VPN changes in 20.3.0? Is the restriction coming from Parallels, or a change in macOS Sequoia's network access policy?
Found the root cause: `nehelper: [com.apple.networkextension:] Local network denied by preference for iTerm (com.googlecode.iterm2)`
Thank you for sharing. I had the same problem, I was getting "no route to host" when trying to ping the VM IP address. On the Mac, in "Privacy & Security", I gave iTerm access to the "Local network".