VMware Communities
rawbling
Contributor
Contributor

DHCP in Bridged Mode not Working

Wondering if anyone else is having this issue.

My Setup: MacBook Pro (Retina, 15-inch, Late 2013)

OSX Yosemite v10.10.5

VMware Fusion Version 8.0.0 (2985594)

Guest OS - Windows 10 Enterprise Edition x64

The guest is able to pull an IP address via DHCP in NAT mode.

The guest is unable to pull a DHCP address when using the wireless adapter connecting to our Cisco AP's, while in Bridged mode. If I set a static IP, it works fine.

I am able to pull a DHCP address connecting to the network via a wired connection, and also connecting to a hotspot (my iPhone).

Reply
0 Kudos
11 Replies
nancyz
VMware Employee
VMware Employee

Hi rawbling,

Welcome to Fusion community.Smiley Happy

The guest is unable to pull a DHCP address when using the wireless adapter connecting to our Cisco AP's, while in Bridged mode. If I set a static IP, it works fine.

Could you please provide which kind of Cisco AP your are using? Thanks.

Reply
0 Kudos
rawbling
Contributor
Contributor

So far I have tried a 2702i AP joined to a 5500 series controller. And as an additional test, setup a stand-alone 2602i AP.

At home, I have tested with a Meraki, Netgear and Motorolla APs, and they all worked as they should.

-RL

Reply
0 Kudos
nancyz
VMware Employee
VMware Employee

Hi rambling,


Thanks for your update.


So far I have tried a 2702i AP joined to a 5500 series controller. And as an additional test, setup a stand-alone 2602i AP.

Could you help to upload your sniffer when this issue happen? Please use the following steps to get the sniffer.

1. Get the working network adapter on your Mac OS

launch terminal, and type 'ifconfig', find the BSD name of the network adapter which is connected to the Cisco AP, say, en0.

2. Install wireshark in your GOS

3. Do a sniffer for your Mac adapter using the following command ( assuming that you installed Fusion in Application Folder)

sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-sniffer -w /path/to/sniffer.pcap en0

Here, en0 is the adapter which Fusion is bridging to.

Change the permission pcap file to '777' in terminal.

4. Launch wireshark in your GOS and set it to capture the current bridged network adapter, say 'Local Area Connection', change your VM to bridged mode.

save the capture packets in GOS.

5. Terminate the sniffer process in step 3 using  'Ctrl + C'

6.Upload the saved files in steps 3 and 4. Smiley Happy


Thanks in advanced.

Reply
0 Kudos
sockmonkey72
Enthusiast
Enthusiast

I am having a similar issue using Git in NAT mode. The host name cannot be resolved. The same VM using Bridged mode works fine, but then shows up on my intranet, which isn't ideal.

Reply
0 Kudos
rawbling
Contributor
Contributor

Sorry, I was unable to get vmnet-sniffer to work, so I ran Wireshark from both the host and guest sides. Hopefully these help.

Some additional info that may or may not be useful;

If DHCP were to be successful on the guest, it would draw an IP address in the range of 10.21.3.50-253.

Reply
0 Kudos
nancyz
VMware Employee
VMware Employee

Thanks for your help. I'll forward this problem to our dev and see if they could do something. Smiley Happy

Reply
0 Kudos
www23456
Contributor
Contributor

from the guest pcap file: VM sent several dhcp discover packets out with VM's Ethernet mac address, UDP port from bootpclient (68) to 67 (bootp server). inside the bootp 'discover'  packet is the client mac address: VM's mac.

On host pcap:    those discover broadcast pkts being modified: ethernet source address is the 'Apple wifi mac addr' and the mac client addr is not changed (vm's mac address).

There is no dhcp offer coming back from Cisco DHCP server. that is why the vm could not get the ip address.

you might need to configure cisco dhcp server to allow multiple dhcp discover/request with same Ethernet source address since VMs or host using same source mac address.

Or use NAT or use static ip address for workaround.

Reply
0 Kudos
rawbling
Contributor
Contributor

www23456 - I have passed your analysis on to one of our engineers to see what he can find. At this point I have ruled out the wireless controller, as I can reproduce the issue with a stand-alone Cisco AP (autonomous mode). Once he confirms there isn't an issue with the DHCP server running from our 7200 router, I will open up a TAC case with Cisco on the AP to see if I can find out what is causing this. If I get an answer, I will update the thread.

Thank you and nancyz for the help.

Reply
0 Kudos
Dyenom
Contributor
Contributor

I had this problem a while back.  Make sure the "passive client" feature is enabled on the WLAN on the controller under the Advanced tab.

Ironically, we just upgraded our code to 8.3 and this is now broken again for me.

Reply
0 Kudos
Tech4Humans
Contributor
Contributor

I had a similar problem.

Problem

  • Windows guest using bridged network
  • OS X host using WiFi connection
  • Windows guest could not get address from DHCP server. Could operate fine using statically assigned IP address

Diagnosis and solution

To create a separate network interface, the VM creates a new MAC address, different from the one on the host computer. (On wired Ethernet, I believe this is handled by putting the Ethernet hardware into promiscuous mode and then capturing packets sent to this synthetic MAC address, which makes it appear real to the rest of the network.) With the host on WiFi, the VM has to forward the packet to the WiFi access point using the hosts MAC address and encryption keys, for security. This means the DHCP server gets a request for an address to be assigned to a MAC address that is not the MAC address of the requester. That is not normal, and can be used by someone malicious to take down a DHCP server by allocating its entire pool of addresses to fake clients. For this reason, some servers and networks have policies to reject such requests.

You can work around this problem by using NAT or a statically assigned IP address. I solved the problem by getting my network administrator to change the policy in the network configuration, specifically, by disabling DHCP Snooping MAC Address Verification.

Reply
0 Kudos
ColoradoMarmot
Champion
Champion

Many AP's are set to only grant a single IP per MAC address via DHCP.  Any idea if that's how yours are configured?

Reply
0 Kudos