VM MAC address will be changed to macOS MAC address when sending/receiving packets to/from router via Wi-Fi, and if certain security check in enabled on Server/Router , they will 'think' the request(say, DHCP request) is invalid.
Does your Bridged VM has DHCP problem when using wired network, say, Ethernet adapter?
thanks for your answer.
There is no security Mac filter in the router. The bridge VM is working fine with DHCP and wired network.
The problem comes when I update the Mojave OS.... before this update all this settings were so smooth.
You're having the same issue as me, it's a bug, see this post: VMware Fusion - incorrect MAC address bridge mode - dhcp broken
PACKETS DON'T LIE - This is NOT a security issue, VMware had this working up until Fusion 10. This also works in Parallels. The issue is in Fusion 10&11, they are using the incorrect MAC address in the DHCP DISCOVERY packet.
1 person found this helpful
I recently run into a similar issue, i couldn't access my local network from a Windows 7 Pro VM with bridged network while on wifi, but everything's running fine with the ethernet cable.
After a lot of troubleshooting i finally discovered a solution, in short i'll try to explain my tests and the workaround which solved the problem.
During my extensive tests, i installed many fresh VM and the most meaningfull clue had been to discover that i didn't have any issue with wifi bridged networking in a Windows 10 guest VM, nor in a legacy Windows XP VM ... so there should have been something very specific to compatibility with Windows 7!
Then i noticed that the network card driver installed in the Windows 7 VM and in the Windows 10 VM are not the same... the Win7 had the "Intel(R) Pro/1000 MT Network Connection" while the Win10 was running a "Intel(R) 82574L Gigabit Network Connection"; i decided to further investigate, and looking into the .vmx file of both VM i realized the following difference:
ethernet0.virtualDev = "e1000"
ethernet0.virtualDev = "e1000e"
I manually altered the value of the "ethernet0.virtualDev" param in the Windows 7 .vmx file, as follows:
ethernet0.virtualDev = "e1000e"
When i restarted the Windows 7 VM, the guest OS has immediately detected a network device recognized as a "Intel (R) 82574L Gigabit Network connection" and it has installed new drivers for it ... and then, ta-dahhh, everything's was finally running well again even with bridged networking via my Macbook Pro integrated wifi card!!!
I suppose that in the recent Fusion updates there has been a regression in the code (maybe in a kext) that emulates the Intel E1000 network card, creating problems and issues when the bridge mode involves the wifi card.
I sincerely hope that my experience can be useful to solve your problem.
Thank you, thank you, thank you! I've been tearing my hair out for a week
Thanks Alekappa - your process fixed my issue as well! Legend.
My issue was similar to the OP's - but bridge mode worked reliably from a Windows 7 VM (Migrated OSX Sierra/VMWare Fusion 8) right up until i tried to establish a second connection out of the VM. For example, i could run some software i use that uses port 44818, but when i'd start VNC viewer on 5900, the network connection would fail and require a reboot of the VM to establish any connection in any mode (bridged or NAT).
This also only appeared on wi-fi, with everything OK when i'd use a USB-C to ethernet adapter for a hard wired connection.