VMware Communities
Legend0
Enthusiast
Enthusiast

VMware Fusion - incorrect MAC address bridge mode - dhcp broken

Hi,

This is a bug with Vmware version 10 - 11.0.2  still not fixed. MacOS latest on new gen macbook with USB-C.

Currently you have to set a static IP on the Virtual Machine if you want to connect.

DHCP DISCOVER packet egresses Fusion with MAC of HOST machine instead of Virtual Machine NIC.

Please FIX!

Tags (1)
17 Replies
Legend0
Enthusiast
Enthusiast

bump

Reply
0 Kudos
TheLoneWanderer
Contributor
Contributor

I am currently having this same issue. Can we have someone take a look at this?

Legend0
Enthusiast
Enthusiast

Mikero  - can we get an answer on this, please? Any chance bridge mode on wifi interface will be fixed?

Reply
0 Kudos
AAyestaran
Contributor
Contributor

Jan 27 - 2019 and this is still broken.

Almost make this release totally useless. The only way to make network work is to select "share with my Mac" which makes address resolution painfully slow.

What is the official response from VMWare about this bug? Is there an ETA?

AA.

Legend0
Enthusiast
Enthusiast

Can we get an official response please?

Reply
0 Kudos
wila
Immortal
Immortal

Hi,

For your information, the Community Forum is not an official support-forum and is not officially monitored by VMware Support or Product Managers.

This is a community based forum where VMware Fusion users help other users.

So most of the time -like now- you get an answer from a volunteer.


As a side note there are VMware employees who keep an eye on the forums and try to help out, but they might not see every post and most - if not all of them - are doing so in their own free time.

To get official support please go to: Fusion Support and open a ticket at File a Support Request

I do not work for VMware, so my response is not official, but with all that out of the way.

The thing is that this thread is the only thread that I am aware about which talks about this issue.

For the sake of sanity I just unhooked my macbook pro from the LAN and connected it to WiFi and have a Windows 10 guest request a new IP via DHCP.

It had no problem doing so and it was pretty transparent.

If it would request the IP with the mac address of my host then there would have been a conflict.

I'm not sure why you are having problems, but I would suggest to reinstall VMware Fusion as a first matter of troubleshooting.

If that does not help, then please do open a ticket via the links I provided earlier, so that you really have someone from VMware looking into your issue.

hope this helps,

--

Wil

| Author of Vimalin. The virtual machine Backup app for VMware Fusion, VMware Workstation and Player |
| More info at vimalin.com | Twitter @wilva
Reply
0 Kudos
alekappa
Contributor
Contributor

As far as i can understand from your screenshot, you were running a OSX guest VM with bridged networking on wifi, is it correct?

I'm asking that because i just made an interesting discover and a workaround which solved my problem, i really don't want you waste your time but it may be worth to have a look to my post in this thread:

Network settings Wifi bridge issues

Best regards,

Alex

Reply
0 Kudos
wila
Immortal
Immortal

As this topic gets a bump... (and I remember something)


Let me correct something I said in my previous reply:

For the sake of sanity I just unhooked my macbook pro from the LAN and connected it to WiFi and have a Windows 10 guest request a new IP via DHCP.

It had no problem doing so and it was pretty transparent.

which actually turns out to be a confirmation on what the TS discovered.

Why?

Because I completely forgot that my WiFi only allows a limited list of MAC addresses to connect to the WiFi, so it must have used the host's MAC address instead of the guests one.

Just verified my WiFi's filter list and there is NO vmware mac address in that list.

My apologies for drawing the wrong conclusion.

However I do hope though that you followed my advice to open a support issue on this and I recommend everybody who bumps into this and need to get it fixed to do the same.

--

Wil

| Author of Vimalin. The virtual machine Backup app for VMware Fusion, VMware Workstation and Player |
| More info at vimalin.com | Twitter @wilva
Reply
0 Kudos
Legend0
Enthusiast
Enthusiast

The bug is present over WiFi. Used to work up to fusion 8, 9 broke functionality. The bug (as listed above and documented with packet captures) is due to the host's MAC Address being used instead of the VM's. Reinstalled VMware Fusion as well as fresh install of Host MacOS 10.14.

Reply
0 Kudos
Legend0
Enthusiast
Enthusiast

Additionally, I've called VMware support, they are clueless and incapable of helping. The only support engineers from VMware that provide sufficient support are for enterprise products. The second packet captures are mentioned... "what are packets?"

The last time we leveraged the community to get the menubar button restored, and it was a pleasant surprise. Hoping for the community to get this long time bug solved. Clearly, it's the wrong pointer/reference in the code. Simply change which MAC address is being referenced and the bug is fixed. Parallels has this functionality and has had it for many years, as did VMware, so anything short of acknowledging this is a bug in Fusion's code is unacceptable.

Reply
0 Kudos
Legend0
Enthusiast
Enthusiast

Alekappa - appreciate your response and attempt. Unfortunately, the VM is still sending a DHCP REQUEST with the incorrect MAC address in the packet.

Reply
0 Kudos
wila
Immortal
Immortal

Hi,

You might have to get to the right folks at VMware support.

Perhaps Mikero​ can help to get the ticket seen by the right folks.

Note that in the other thread that alekappa references, there is a reply from VMware employee nancyz and it seems that this behavior is by intent.

IOW, it might be an intended change to make life easier for other users where the side effects that you are now bumping into have been overlooked.

Perhaps changing the network adapter to e1000e does help as well.

It certainly is a much better performing virtual network adapter as the e1000 one. (another good point from alekappa!)

PS: Fusion 9 never existed, I think you meant to say that it broke in Fusion 10.

--
Wil

| Author of Vimalin. The virtual machine Backup app for VMware Fusion, VMware Workstation and Player |
| More info at vimalin.com | Twitter @wilva
Reply
0 Kudos
Legend0
Enthusiast
Enthusiast

Wila,

With all due respect, - Do you believe something that once worked, that no longer, and can be proven in the packets as sending the incorrect MAC address as "working as intended?"

If you read above, I tried alekappa's e1000e mod, - didn't work.

Yes, fusion 10.

Worked fine up until 8. Now i'm stuck on Parallels until this is fixed. 10 took away our menubar, 11 brought it back (Thanks to Mikero)... So how about fixing Bridge mode? (see above screenshot)

Reply
0 Kudos
wila
Immortal
Immortal

Hi,

It's a pity that changing the NIC to an e1000e one did not help resolving your issue.

I believe that what VMware changed and tested, functioned within their testing constraints.

But also believe that what you are bumping into is an unintended side effect.

IOW, your use case did not fall within their current testing regime. I am not debating if it is a bug or not (it's a bug from my P.O.V. as well).

Like you I would love to see this addressed, although I'm sure that your need is higher than mine.

Anyways.. let's not get carried away with semantics and wait for VMware to react.

--

Wil

| Author of Vimalin. The virtual machine Backup app for VMware Fusion, VMware Workstation and Player |
| More info at vimalin.com | Twitter @wilva
Reply
0 Kudos
alekappa
Contributor
Contributor

I'm afraid it will be quite tough, have a look to this thread in the Apple Developer Forums:

https://forums.developer.apple.com/thread/106768

As far as I could understand, it seems that Apple's dropping support for MAC address spoofing... :smileyconfused:

Legend0
Enthusiast
Enthusiast

Parallels supports it and it works just fine.

There is nothing wrong with Bridging to WiFi when using a Unique MAC Address from the VM/VNIC.

Reply
0 Kudos
carrion
Enthusiast
Enthusiast

What's shown in the bug.png file in the original post is not a bug - it is the way link layer communication works, and that isn't interfering with DHCP. Instead of looking at the ethernet MAC address of the sender, you need to look at the Client MAC address in the DHCP Discover packet. That is most likely the correct MAC address of your client OS. If not, then something _very_ strange is happening.

VMware's bridge effectively puts the client and host on a separate network segment from the network segment the host is already connected to (the one with the DHCP server). This means that the client can't talk directly to the DHCP server without going through an intermediary device (the host in this case). The host relays the client's DHCP Discover to the DHCP server and since the host is the device that's actually transmitting onto that network segment, it _must_ use it's own MAC address at the link layer. The DHCP Discover packet will nevertheless contain the client MAC address, and the DHCP server will be able to respond with an appropriate DHCP Offer.

If the DHCP server is on a network where security is an issue, it would not be surprising if all DHCP Discover packets with a mismatch between the link layer MAC address and the Client MAC address are automatically discarded. This is done to protect against DHCP starvation attacks. Unfortunately, it also means that devices behind a bridge or a switch can't obtain IP addresses on these networks. If this is your situation, you might try talking to the network admin about registering the client MAC address as a valid MAC address, and having their security software check the Client MAC address for validity before tossing DHCP Discover packets with mismatched MAC addresses. FWIW this security issue is also the explanation offered by VMware employee nancyz in the alekappa thread. (Note that security measures would most likely result in no DHCP Offers being sent but bug.png clearly shows DHCP Offers, so security measures may not explain the original poster's problems.)

Please no flames - I'm not trying to say that there isn't a problem, nor am I claiming that security measures explain all the problematic behavior reported by various posters. This is just an effort to explain why the bug.png image in the original post does not indicate a problem, and to offer a little clarity about how the link layer works.