Network Connection Issues with macOS 15 VM in Parallels Desktop

K

kissy

Bit poster
Description:
I've encountered several network connectivity issues when creating a new MacOS 15 virtual machine in Parallels Desktop:

Shared Network Problems


The MacOS 15 VM is assigned an IP address in the 192.168.64.xx range and cannot use shared networking
In contrast, Windows VMs (with IP addresses in the 10.211.xxx range) work perfectly fine under the same conditions


VPN Compatibility Issue


When VPN is enabled on the host machine, the MacOS 15 VM completely loses network connectivity
Windows VMs maintain normal network access even with host VPN enabled

Environment:

Virtualization Software: Parallels Desktop (PD 20 For Mac Pro Edition)
Virtual Machines: MacOS 15.2, Windows 11
Host System: (MacOS15.2)

Confirmed Behavior:

Issues only occur with MacOS 15 VM
Different IP subnets are assigned to different OS VMs
VPN has a significant impact on MacOS VM network connectivity

Questions:

Has anyone else experienced similar issues?
Are there any known solutions or workarounds?
Has this been acknowledged as a known issue by Parallels?
 
I have a similar problem, but the IP address that DHCP assigns is from the 169.254.x.x range. Manual IP assignment (10.211.x.x) doesn't solve the problem. The version of macOS guest VM is the same as the host's one: 15.2 (Sequoia)
 
I can confirm this as well. Installing the guestOS macOS 15.2.0 dies if the VPN is turned on. GuestOS will terminate if you try to boot it from Parallels Control Center with the VPN turned on.
 
I am having same issue. Currently on macOS 15.2 host OS and macOS 12.6 guest OS on M1 physical MacBook Pro.

When guess VM is configured to shared network for 10.211.55.1 subnet, it reverts back to 192.168.64.1 subnet and though sometime, i could access internet, the vpn connection is not shared. This is frustrating issue and Parallels KB instructions to fix it are not working (https://kb.parallels.com/129984/)
 
Same issue here and very annoying since I cannot access the web server in my Ubuntu VM. But even with an IP address in another segment, there should be a route in the host to fix this. But it would be better if _all_ virtual machine are in the same network.
 
I guess no one has fixed this issue? I made a support ticket and if resolved, I will try to post it here.

My setup is a host M series macbook running Sequoia using an OpenVPN client. I have a windows 11 vm via Parallels. I have internet access for both systems when using the VPN BUT I can't access anything else on the .1 subnet. Which is what I really need on the host. I have multiple vpn conf edits pushing the .1 subnet but the host mac refuses to abide by those pushed rules from the vpn server. I have confirmed it's parallels causing this because the mac worked perfectly with the VPN before installing parallels. on two systems. No matter how I disable networking options in parallels and the VM, it continues to not recognize the .1 subnet over the vpn. I've also tried some route swapping to use the VPN route which does work but it's temporary until the VPN turns off, then you'd need to manually trigger the route swap again. I don't think I should have to make loads of conf files that auto trigger when the vpn turns on etc, when parallels is the cause. I'm trying to find a setting or 1 config file to make that removes whatever hold parallels has on the host networking settings.
 
Hi, did anyone get ant reply from Parallels about this problem? I have a similar problem, MacOS 15.4.1 Parallels
Version 20.3.0 (55895)
 
There is a Parallels Preview version at https://my.parallels.com/desktop/preview that solves this problem. I had that installed and it worked fine, but there were other issues e.g. that my Laravel/homestead box didn't want to start properly. So I had to rollback. But it might work for you.

If you can't download it, I suggest you contact Parallels support and ask for it.
 
UlfJ2 said:
Hi, did anyone get ant reply from Parallels about this problem? I have a similar problem, MacOS 15.4.1 Parallels
Version 20.3.0 (55895)
Click to expand...
I am still working with support on the issue. Their support is not very good with communication so far. I will update this when I know more
 
Good morning. I was able to gain connectivity by modifying the network source to default adapter (bridged) in place of shared recommended. I also assigned a static address in place of using DHCP with IPv4 using a gateway for the allocated range of x.x.x.1. A caveat to this is that this config (Mac VM) will not utilize the VPN connection, whereas with the default settings of shared recommended, does use the VPN connection (VM). In addition to this, DHCP is disabled globally which is rather pointless. This config parameter should be isolated to a singular device. Nonetheless, while this makes the internet reachable from the Mac VM, it hoses up the config for other VM's. The host endpoint does maintain ingress/egress traffic with the VPN connection, whereas the Mac VM as noted above hangs onto the public. From a security perspective this is a no go.
 
I'm still "sort of" working with support. They opened a development ticket which IMO is a blackhole. I'm not sure I'll get a response back since I've been talking to support for over a month now... I did finally get access to the preview builds since someone above said that fixed it for them. So I'm going to see if that resolves my issues to let support know whatever they changed in the preview needs to be in the live version.

The solution Bjn@ry mentioned wouldn't work for me. I have users that need this to be as simple as possible. Just using a VM is difficult for some. Add on a VPN, it's even more complicated for them. Restricting their laptops to static IPs is a no go. Appreciate the effort of the solution but for my case, it's not viable.

I'll keep everyone updated when I get more info
 
Update: The preview build did not fix the issues on systems already affected. I was however able to pin point the exact issue for me and send it to the dev team. My OpenVPN uses the utun4 network interface when enabled (this is by default). It's suppose to switch over 192.168.1 traffic to also use that network interface automatically thanks to server configs that download to the VPN client (route all network traffic over the VPN). The issue is, once Parallels is installed, the VPN cannot tell the 192.168.1 traffic to switch to the same interface the VPN is using. It stays on the default en0 Network interface. If you manually change the network interface for the 192.168.1 traffic on your mac, it works temporary as those changes only stay until a system restart. I do not believe I should have to make scripts that update that network interface myself. Parallels needs to not mess with these settings. Although it is very strange that even after wiping a system, it still acts this way on a fresh macOS install. Only brand new Macs that have never had Parallels installed, work totally fine with my VPN. Very strange and annoying. Hope this insight helps for some. Try manually changing the network interface for your subnet traffic that's not working and see if it helps. Let Support know if that fixes your issue. The more people reporting the same thing the faster it will get resolved.
 
I had this problem with various older VMs after upgrading Parallels, namely getting a 169.x.x.x address, regardless of the type of "Source" (Bridged, Shared Network, etc). I eventually solved it (at least for my case) by going to the affected VM's Configuration settings, Hardware tab, removing the "Network" item completely, then adding it back. After that, the networking in the affected VMs started working properly. Hope that helps.
 
@JohnJohnD - Thank you so much for sharing your success story. I was having the same probelm of getting a 169.x.x.x address assigned, but unlike others in this discussion I am not using a VPN. Deleting the Network and adding it back solved my issue. Thanks again!!!
 
DakotaH1 said:
Update: The preview build did not fix the issues on systems already affected. I was however able to pin point the exact issue for me and send it to the dev team. My OpenVPN uses the utun4 network interface when enabled (this is by default). It's suppose to switch over 192.168.1 traffic to also use that network interface automatically thanks to server configs that download to the VPN client (route all network traffic over the VPN). The issue is, once Parallels is installed, the VPN cannot tell the 192.168.1 traffic to switch to the same interface the VPN is using. It stays on the default en0 Network interface. If you manually change the network interface for the 192.168.1 traffic on your mac, it works temporary as those changes only stay until a system restart. I do not believe I should have to make scripts that update that network interface myself. Parallels needs to not mess with these settings. Although it is very strange that even after wiping a system, it still acts this way on a fresh macOS install. Only brand new Macs that have never had Parallels installed, work totally fine with my VPN. Very strange and annoying. Hope this insight helps for some. Try manually changing the network interface for your subnet traffic that's not working and see if it helps. Let Support know if that fixes your issue. The more people reporting the same thing the faster it will get resolved.
Click to expand...

I'm posting again that I haven't heard anything from support. Still no progression on this issue. I don't think they will resolve it. Thankfully my company is moving away from requiring parallels. So I shouldn't have to deal with this in the future.
 
Well I couldn't wait for someone to figure out a fix so I made some scripts to fix the issue for me. It's worked on an m series and intel macbook pro. Here is what I did.
I also don't know if it's a parallels specific error now. Parallels definitely triggers the issue, but I had this issue show up on a mac I never installed parallels on today after the issue showing up on about 20 intel macs and not showing on 4 M series macs. Either way, this should solve the issue.

This only works for the base Admin account on your mac.
Make a txt file named vpn-route-manager.sh and place it in the admin home folder
Paste this inside the txt file:
Code: 
#!/bin/bash

# Wait for VPN interface (utun4, tun0, etc.) to appear
while ! ifconfig | grep -q "utun"; do
  sleep 1
done

# Get VPN interface name (e.g., utun4)
VPN_IF=$(ifconfig | grep '^utun' | cut -d: -f1)

# Delete conflicting route (if needed)
sudo route -n delete 192.168.1.0/24 2>/dev/null

# Add route via VPN gateway (replace 192.168.4.1 if necessary)
sudo route -n add 192.168.1.0/24 -interface $VPN_IF

echo "[$(date)] VPN route applied: 192.168.1.0/24 → $VPN_IF" >> ~/vpn-route.log
This will be used to swap the network interface for the .1 subnet after the VPN is started

Make another txt file named local.vpnroute.plist and place it in Library/LaunchAgents
Paste this inside the txt file:
Code: 
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>local.vpnroute</string>
  <key>ProgramArguments</key>
  <array>
    <string>/bin/bash</string>
    <string>-c</string>
    <string>~/vpn-route-manager.sh</string>
  </array>
  <key>StartOnMount</key>
  <true/>
  <key>WatchPaths</key>
  <array>
    <string>/var/run/resolv.conf</string>  <!-- Newer macOS versions -->
    <string>/etc/resolv.conf</string>      <!-- Legacy -->
  </array>
  <key>RunAtLoad</key>
  <true/> <!-- Run at startup -->
</dict>
</plist>
This is what watches for changes in the network settings. When the vpn starts up, it runs the .sh file we made earlier, swapping the interface on the .1 subnet

Now you need to make the .sh file executable. Open terminal and run
Chmod +x ~/vpn-route-manager.sh

I don't remember if I needed this but, only run this if you are not concerned about password requirements for changing routing settings. Run in terminal
echo "$USER ALL=(ALL) NOPASSWD: /sbin/route" | sudo tee /etc/sudoers.d/vpn-route

Now we need to run the plist file in the terminal
launchctl load ~/Library/LaunchAgents/local.vpnroute.plist

These changes will persist through reboots etc.

Turn on the VPN and ping something on the .1 subnet. It should work now. This has worked for me on 2 macs and I will do more soon. Hope this helps someone else!
 
DakotaH1 said:
Well I couldn't wait for someone to figure out a fix so I made some scripts to fix the issue for me. It's worked on an m series and intel macbook pro. Here is what I did.
I also don't know if it's a parallels specific error now. Parallels definitely triggers the issue, but I had this issue show up on a mac I never installed parallels on today after the issue showing up on about 20 intel macs and not showing on 4 M series macs. Either way, this should solve the issue.

This only works for the base Admin account on your mac.
Make a txt file named vpn-route-manager.sh and place it in the admin home folder
Paste this inside the txt file:
Code: 
#!/bin/bash

# Wait for VPN interface (utun4, tun0, etc.) to appear
while ! ifconfig | grep -q "utun"; do
  sleep 1
done

# Get VPN interface name (e.g., utun4)
VPN_IF=$(ifconfig | grep '^utun' | cut -d: -f1)

# Delete conflicting route (if needed)
sudo route -n delete 192.168.1.0/24 2>/dev/null

# Add route via VPN gateway (replace 192.168.4.1 if necessary)
sudo route -n add 192.168.1.0/24 -interface $VPN_IF

echo "[$(date)] VPN route applied: 192.168.1.0/24 → $VPN_IF" >> ~/vpn-route.log
This will be used to swap the network interface for the .1 subnet after the VPN is started

Make another txt file named local.vpnroute.plist and place it in Library/LaunchAgents
Paste this inside the txt file:
Code: 
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>local.vpnroute</string>
  <key>ProgramArguments</key>
  <array>
    <string>/bin/bash</string>
    <string>-c</string>
    <string>~/vpn-route-manager.sh</string>
  </array>
  <key>StartOnMount</key>
  <true/>
  <key>WatchPaths</key>
  <array>
    <string>/var/run/resolv.conf</string>  <!-- Newer macOS versions -->
    <string>/etc/resolv.conf</string>      <!-- Legacy -->
  </array>
  <key>RunAtLoad</key>
  <true/> <!-- Run at startup -->
</dict>
</plist>
This is what watches for changes in the network settings. When the vpn starts up, it runs the .sh file we made earlier, swapping the interface on the .1 subnet

Now you need to make the .sh file executable. Open terminal and run
Chmod +x ~/vpn-route-manager.sh

I don't remember if I needed this but, only run this if you are not concerned about password requirements for changing routing settings. Run in terminal
echo "$USER ALL=(ALL) NOPASSWD: /sbin/route" | sudo tee /etc/sudoers.d/vpn-route

Now we need to run the plist file in the terminal
launchctl load ~/Library/LaunchAgents/local.vpnroute.plist

These changes will persist through reboots etc.

Turn on the VPN and ping something on the .1 subnet. It should work now. This has worked for me on 2 macs and I will do more soon. Hope this helps someone else!
Click to expand...
This worked to get the VPN running again. But a couple weeks after using this, it is messing with connecting to local devices. Screen sharing, connecting to a printer etc. Removing this "fix" solve my issues with talking to those devices. I'm back to not having a working VPN again....
 
You must log in or register to reply here.
Back
Top