Shared Network drops DHCP after sleep; prl_naptd not running

Discussion in 'Parallels Desktop on a Mac with Apple silicon' started by Don Awalt, Oct 30, 2025.

  1. Don Awalt

    Don Awalt Hunter

    Messages:
    203
    Parallels 26.1.1 (Apple silicon) -- Shared Network drops DHCP after sleep; prl_naptd not running while bridge100remains

    Host(s):

    • MacBook Pro M3 Max (Wi-Fi only), macOS 26.0.1 "Tahoe"
    • MacBook Pro M4 Max (Ethernet + Wi-Fi), macOS 26.0.1 "Tahoe"
    Parallels Desktop: 26.1.1 (latest as of Oct 2025)
    Guest: Windows 11 (Apple silicon build)
    Parallels Tools: up to date
    Network mode: Shared Network (Recommended)
    VPN: none
    IPv6: disabled on LAN/router

    Summary

    On my M3 Max host using Shared Network, the Windows VM loses network about once per day (often after lid-close sleep). Inside Windows, the network troubleshooter reports "No DHCP server was found." IPConfig shows a link-local 169.254.x.x with no gateway. Restarting the VM or "Restore Defaults" in Parallels Network settings fixes it immediately. The same VM on an M4 Max host (Ethernet present) has been stable, never losing the network.

    This indicates a host-side Shared-Network/DHCP service failure rather than a guest issue.

    Repro steps (reliable on M3 Max Wi-Fi host)

    1. Set VM to Shared Network (Recommended).
    2. Close MacBook lid for several hours/day or two (host sleeps).
    3. Open lid; return to VM desktop.
    4. VM has no network; Windows 11 shows 169.254.x.x and No DHCP server.
    Expected: VM regains its 10.211.55.x address within a few seconds after wake.
    Actual: VM self-assigns 169.254.x.x and stays offline until host service is restarted.

    What I observed when failure occurs

    In Windows (guest):

    • ipconfig → IPv4 Address 169.254.x.x, no gateway, mask 255.255.0.0
    • Windows Network Troubleshooter → No DHCP server was found.
    On macOS (host):

    • Parallels' NAT routes still present:
    · netstat -rn | grep 10\.211

    · # Example output when broken:

    · 10.211.55/24 link#XX UC bridge100 !

    · 10.211.55.255 ff.ff.ff... UHLWbI bridge100 !

    (So the bridge and routes remain.)

    • But the NAT/DHCP daemon is not running:
    · ps aux | grep prl_naptd | grep -v grep

    · # (no output)

    When working normally, I see a root-owned process like:

    /Applications/Parallels Desktop.app/Contents/MacOS/prl_naptd start

    Note on Parallels 26.x: the legacy vnic0/vnic1 interfaces no longer appear in ifconfig. Shared networking now runs over bridge100 with prl_naptd. So absence of vnic0/vnic1 is expected; the key signal is whether prl_naptd is alive.

    Why I believe this is a Parallels bug

    • The VM is healthy (reboots fix it).
    • The host still shows the bridge100 routes for 10.211.55.0/24, but Parallels' DHCP/NAT daemon (prl_naptd) is gone.
    • As soon as I restart the Parallels network layer (see "Fixes/Workarounds"), DHCP immediately works and the VM gets 10.211.55.x.
    • The same VM on a different host (M4 Max with Ethernet present) has been solid for days, suggesting a host sleep/Wi-Fi + prl_naptd interaction on the M3 Max specifically.
    This strongly points to prl_naptd crashing or failing to restart after host sleep on certain Apple silicon + Wi-Fi scenarios.

    Further proof: Immediate recovery (no Mac reboot)

    • Shut down all VMs (not Suspend).
    • Parallels Desktop → Settings → Network → Restore Defaults → approve admin prompt.
    • Start the VM → it instantly gets a 10.211.55.x address again.
    This appears to relaunch prl_naptd and rebind to bridge100.

    Technical Data Report submitted, #504431174
     
    ArpadT likes this.
  2. Don Awalt

    Don Awalt Hunter

    Messages:
    203
    Anyone from Parallels that can comment? I have further narrowed this down, if the laptop is locked but lid up, no issues. If the lid is closed, it will lose its connection. I have ll the settings correct to keep the computer going and not falling into sleep, to th extent Apple lets us - there is likely some deep sleep situation it gets into.

    Please fix this - it fails every day! Technical Data Report submitted, #504431174
     
  3. Don Awalt

    Don Awalt Hunter

    Messages:
    203
    This has been over a week (and the problem has gone on much longer). Can't I get a reply from anyone from Parallels on this? The simple fact is that Shared Network loses its connection when the laptop lid is closed. I have submitted a technical report. I am a subscriber. Why can't I get at least an acknowledgment that it's a bug being worked on, or request for more info, a workaround, anything? Is this the way you deal with customers, folks at Parallels? Should I start looking for VM options with better support?
     
  4. ArpadT

    ArpadT

    Messages:
    1
    I have the same problem. I had this before the 26 update occassionally (1-2/week), now I have this everytime. I need to turn off networking and back on each time I leave my Mac to sleep.
     
  5. emotional_lau

    emotional_lau

    Messages:
    1
    I have the same issue and it takes me an hour trying to find out what's wrong with my mac.Luckily after I reseting all the network settings and installing a 26.1.2 version parallels,the issue got solved.I think it's a bug in 26.1.1 version and it gets fixed in 26.1.2.
     
  6. Don Awalt

    Don Awalt Hunter

    Messages:
    203
    @emotional_lau interesting, I"ll try it again thanks. I have been running bridged, albeit with some compromises for my setup.

    Question - I found what kills the connection is closing the lid on the MacBook Pro laptop - that puts the Mac into a deep sleep, no matter what the settings are, that Parallels networking doesn't wake up from. Do you run this on a laptop, and if so with the lid closed for extended periods (like overnight)?
     
  7. Don Awalt

    Don Awalt Hunter

    Messages:
    203
    @emotional_lau failed for me today. I went 5 hours with the lid closed, opened the Mac up tonight, connection was lost and never came back. :-(
    Isn't it funny Parallels never replies on this. What lousy forum support for subscribers.
     

Share This Page