Fusion DHCP not handing out a DNS server after upgrade to Sequoia 15.4

[Bigdave1357]

After recently upgrading to Sequoia 15.4 I've noticed that my Windows guest shows no internet connection when running in NAT mode.

Switching to Bridged fixes the issue.

Further investigation shows that when in NAT mode, Windows cannot determine a DNS server from the DHCP service running within Fusion networking. If I configure Windows to use a manual DNS server, connectivity is restored. Consequently, this isn't an IP level issue - packets are transiting fine - the problem is the lack of a resolver.

I'm not yet able to say for certain that this has caused by the MacOS upgrade, but the NAT facility has been very stable recently and the only thing changing my setup is MacOS, a few days ago. I have not recently installed a Windows update.

Anyone else seeing this?

[Technogeezer]

I'm not seeing this on Sequoia 15.4 and Fusion 13.6.3.

Can you post a copy of the files /Library/Preferences/VMware\ Fusion/networking  and /Library/Preferences/VMware\ Fusion/vmnet8/*.conf so we can double check the Fusion networking configuration?

------------------------------
- Paul (technogeezer)
vExpert 2025
------------------------------

[Cityangels]

Hi Paul,

Here are a zip file with my configuration files.

Best Regards
Anders

Attachment(s)

FilesToSend.zip   8 KB 1 version

[Bigdave1357]

Here are my files

Attachment(s)

Archive.zip   3 KB 1 version

[Bigdave1357]

Any updates on this Paul?

The issue seems to have developed further with the latest version of Sequoia in that after my MBP sleeps, on waking the host networking is completely offline, regardless of if I'm using NAT or bridged networking. To recover I have to flip the network from bridged to NAT (which is not working as per the original post) and then back to bridged. Normal operation then resumes until the next sleep.....

[Technogeezer]

Nothing out of the ordinary with the Fusion networking config.

I do wonder if the Mac going to sleep when the VM is running is part of the problem. macOS deciding to sleep has been problematic for Fusion for quite a while. 

It's interesting that the host networking is offline after resuming from sleep. 

------------------------------
- Paul (technogeezer)
vExpert 2025
------------------------------

[Cityangels]

I've got the exact same problem on my computer. Yesterday I updated to Sequoia 15.4 and then it stopped working with NAT via WMware Fusion. If I switch to Bridged mode, it works.

I've tried reinstalling VMware Fusion but got the same problem anyway. So it seems that you are saying that there is a problem with the DNS lookup via Windows and WMware Fusion.

[Bigdave1357]

One of the processes - either vmnet-dhcpd or vmnet-natd is I believe causing the problem. Probably the former which seems to have stopped handing out a DNS server address when Windows performs a DHCP request to setup networking.

The configuration files requested by Paul might contain some clues. Maybe they got nixed during the installation of the new version.

[chris_lalala]

Same here :/

[John John]

I have a similar issue but my guest OS is Linux. After the Sequoia upgrade DNS stopped working in the guest. My host has Cisco AnyConnect VPN installed, but the problem was present regardless of whether I was connected to VPN or not. Disabling the Cisco Socket Filter DNS proxy in System Settings > Network > Filters worked temporarily until it became re-enabled. I was able to work around the issue by manually specifying my guest OS DNS servers (/etc/systemd/resolved.conf for my machine)

[Classicmac808]

Thanks again for figuring out that this is related to Cisco VPN software. I'm curious if this will fix the issue for you as it did for me.

If you are running AnyConnect:

/Applications/Cisco/Cisco\ AnyConnect\ Socket\ Filter.app/Contents/MacOS/Cisco\ AnyConnect\ Socket\ Filter -deactivateExt

If you are running Cisco Secure Client
/Applications/Cisco/Cisco\ Secure\ Client\ -\ Socket\ Filter.app/Contents/MacOS/Cisco\ Secure\ Client\ -\ Socket\ Filter -deactivateExt

[Neethu Kumar Swamy]

I am able to repro this issue,  a ticket has been raised to investigate it.

[Classicmac808]

Is there any update on this? I'm experiencing the same issue. 

[Tareq Ahram]

After searching extensively and trying every possible proposed solution. my working solution for this was:

1. reninstall/update the NAT driver for network adapter inside Windows
2. restart windows
3. if using vpn then the only working option in VMware fusion is to click "share ip with Mac" 

now VMware Fusion working and internet perfectly stable for 5 days in a row.

[FabienFigueras]

Dear All,

I face the same problem with Windows 11 and RHEL9 regarding Network failures.

For RHEL9

After changing the Network Setting from "Share with my Mac" to "Bridge Wifi" everything is fine.

I notice that for the "Share with my Mac" setting, the bridge used on the Mac level is defined with a network 172.16.50.0/24 with two addresses .1 (should be the Gateway and DNS) and 255 (general diffusion) but in the Guest OS the DNS and Gateway are .2 which lead to DNS requests time out and Network Failure.

So my gess is that the problem is due the DHCP interface between the Guest OS and the Bridge dedicated to "Share with my Mac" which provide wrong Gateway and DNS addresses.

As when the Guest OS used Bridge the correct Gateway and DNS are used with lead to a proper DNS answer and as DNS is the root of TCP-IP network everything is ok after that.

For Windows 

it's the same behaviour the Guest OS got a .2 Gateway and DNS which lead to time out for DNS requests.

And after switching to Bridge Wifi the network is working fine, DNS request return correct values ans Internet is reachable.

By the Way my configuration is 

Sequoia 15.4.1

Fusion 

Player Version 13.6.3 (24585314)

I Hope my contribution could help to troubleshoot this issue.

Kind regards

Fabien FIGUERAS

EPFL 

[Technogeezer]

The gateway and DNS addresses in the NAT segment are correct. The .2 address is listened to by the vmnet-natd process on the host. That provides both the DNS resolver and the NAT gateway. The .1 address on the segment is the host Mac and allows the host to access VM guests and guests to access the host without having to go through the NAT gateway.  The .1 address does not provide DNS or NAT gateway services to the NAT subnet. 

There appears to be a problem with the DNS resolver part of vmnet-natd for some people running Sequoia 15.4.1. (Disclaimer: it works for me with the out-of-the-box Fusion networking setup and a Wi-Fi connection from my M1 Mac mini). 

------------------------------
- Paul (technogeezer)
vExpert 2025
------------------------------

[Technogeezer]

Has anyone experiencing this issue tried adding a custom NAT network through VMware Fusion > Settings > Network and seeing if that works?

------------------------------
- Paul (technogeezer)
vExpert 2025
------------------------------

[Brian Kelly]

Same results.

[Technogeezer]

I find it interesting that your nslookup cisco.com returns an address for cisco.com.localdomain.

Can you run a brief experiment on that new virtual network you've just created?

Shut down the VM and the Fusion GUI.

Open a terminal, and sudo to a root shell.

Open /Library/Preferences/VMware Fusion/vmnet3/dhcpd.conf with your favorite command line text editor (e.g. vi)

Locate the line:

        option domain-name localdomain;

and change it to

        # option domain-name localdomain;

Save and close the file.

Start Fusion and the VM.

Open a command prompt in Windows, run the following commands and post the output (please copy/paste the text from the terminal window into your reply and not a screen shot -- it's easier to deal with in text format).

ipconfig /flushdns
nslookup cisco.com
nslookup cisco.com.
ping cisco.com
ping cisco.com.

------------------------------
- Paul (technogeezer)
vExpert 2025
------------------------------

[Brian Kelly]

Same results.

Also this seems to be just a Windows thing. Booting a TinyCore Linux ISO seems to work properly.

This is on my Intel PowerBook -- I also have an ARM PowerBook that performs the same way.

One other note -- I built a fresh Windows VM that exhibited the same symptoms.

BK

[Technogeezer]

I think you may have edited the dhcpd.conf file for the wrong vmnet. Which file did you edit and which virtual network are you running in that Windows VM? The file you edited has a NAT network segment of 10.251.251.0/24 but the VM is reporting it's using the resolver for the 172.16.217.0/24 network - which is telling me that the virtual network for the Windows VM is not set to the virtual network you edited. 

------------------------------
- Paul (technogeezer)
vExpert 2025
------------------------------

[Brian Kelly]

So I went through and double checked -- not sure how that other IP got it, this time it's not there.

C:\>ipconfig /flushdns

Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

C:\>ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : DESKTOP-Q7TEJ70
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No

Ethernet adapter Ethernet0:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Intel(R) 82574L Gigabit Network Connection
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 10.251.251.128(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Sunday, June 1, 2025 8:43:53 PM
   Lease Expires . . . . . . . . . . : Sunday, June 1, 2025 9:13:52 PM
   Default Gateway . . . . . . . . . : 10.251.251.2
   DHCP Server . . . . . . . . . . . : 10.251.251.254
   DNS Servers . . . . . . . . . . . : 10.251.251.2
   Primary WINS Server . . . . . . . : 10.251.251.2
   NetBIOS over Tcpip. . . . . . . . : Enabled

C:\>nslookup cisco.com
Server:  UnKnown
Address:  10.251.251.2

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Request to UnKnown timed-out

C:\>nslookup cisco.com.
Server:  UnKnown
Address:  10.251.251.2

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Request to UnKnown timed-out

C:\>ping cisco.com
Ping request could not find host cisco.com. Please check the name and try again.

C:\>ping cisco.com.
Ping request could not find host cisco.com.. Please check the name and try again.

C:\>

If there's anything else to try, let me know.

[Brian Kelly]

I have another system, Sequoia 15.5, Intel Core i9, with two Windows VMs (10 & XP).  The Win10 VM works (but the network is set to share a vlan interface that is down[!]) and with WinXP VM does not (I was set to share with the Mac, but changed to be the same vlan & no luck).

I've found a partial work around to get a VM online -- I manually edited the local hosts file with the name/IP of a VPN concentrator, and then once my VPN client connects, everything functions.

Anyone else have any work around ideas?

[Technogeezer]

As a follow on to this thread, the release notes for Fusion 13.6.4 (released 2025-July-15) are saying that an issue with DNS resolution found when using NAT networking is fixed. You might want to upgrade to Fusion 13.6.4 to see if it fixes your issue. 

------------------------------
- Paul (technogeezer)
vExpert 2025
------------------------------

[Bigdave1357]

Perhaps a little too early to be completely sure, but so far, yes, 13.6.4 does seem to fix the DNS issue I first reported. 

Thanks for posting here to let users know that 13.6.4 was available. I have only just realised that the automatic update feature had stopped working, silently, since the update servers appear to have been turned off. I've since read your post about this and comments from other users.

I am incredulous that a company such as Broadcom should have taken a decision to make it more difficult for users to discover and download product updates. Companies generally spend a good deal of time making is less difficult because users are, by and large, not focused on checking continuously for updates and expect their software to at least announce that a new update is available, if not install it for them. Users are not going to develop the habit of making a check to see if Broadcom has announced a new version of Fusion. I work in the security market, a space that we all know Broadcom operates in. It is a requirement of many software accreditation schemes that users are automatically notified. I would love to see the justification for this, from Broadcom.

Had you not posted here, Paul, I would not have known. Thanks for that. I'll now diarise a monthly check to look for updates in the future. Few others will, and the vast number of installed Fusion instances will become out of date, containing unresolved vulnerabilities and bugs with all the problems that entails for their users and for the wider community.

If I didn't know better, and I don't, I'd start to wonder if Broadcom has a plan to dump Fusion. They're certainly not making any noises that would lead users to believe otherwise with their recent behaviour.

[DrBigJim]

I had to rebuild my Mac Studio from factory install in order to resolve another issue and this issue was also resolved with VMWare Fusion. Not sure where in the underpinnings caused the problem. I could not connect to Apple Music, App Store or Apple TV, so this is why I reinstalled the system without restoring from a Time Machine backup.