Wireless Access

Hello,

We enabled "enforce-dhcp" in our AAA profiles when we upgraded to ArubaOS 6.1 around March 2012.  Last week we upgraded to 6.2.1.2 and have had a user report (and we've observed) an IP address clash reported on the VM running Windows: the clashing MAC address is that of the host computer (according to the Windows Event Log).  This happens on Parallels Desktop (the user) and VMware Fusion (me).  The problem goes away when the VM's networking is switched from Bridge Mode to NAT/Shared Mode.

I remember reading that Bridge Mode was incompatible with the "enforce-dhcp" option - I'm guessing because the virtual MAC address doesn't match the outside MAC address and there are problems with the ARP requests probing if the IP address is already in use.

Am I still right in thinking that?  I can't find anything specifically about it in the ArubaOS 6.2 documentation, so I'm not sure where I read it.  Is there somewhere I can look to see the specific problem?

The user reports the problem starting since the upgrade to 6.2 - I can't find anything in the release notes to 6.2 which describe a behaviour change.  Has something changed (perhaps tightening up a hole) or is this a coincidence?

Thanks,

  - Bob

We possibly have two different things going on here:

- What Enforce-DHCP does is NOT allow a client who has not received an ip address as part of the DHCP process into the user table.

- The feature above should not in principle cause a duplicate mac or ip address message.

Please toggle enforce dhcp on and off to determine what is going on.

Did you ever get to the bottom of this Bob? I'm seeing the exact behaviour on a 6.3.0.1 controller.

If you are using VMWARE, the rules are changed, right?  What specifically is your issue?

Hi Colin,

the problem is that on both VMWare Fusion and Parallels both report a duplicate IP address by any guest OS if they are using bridged mode network adapters (I haven't tried it on a Windows host to see if VMWare Workstation or similar has the same issue). Changing over to NAT mode gets around the issue, but I'm not sure what has changed between the 6.1.3.6 release that has been running and 6.3.0.1 release that would cause the bridge mode not to work. I'm yet to do any packet captures or deep investigation on the issue, so that was why I was wondering if Bob found the answer for the difference in behaviour (or not).

Cheers

Ian

I can't remember what tests I did at the time, but I've just had another look at this on a MacBook Pro running 10.8.5 and VMware 6.0.0 Professional with an Ubuntu Linux 12.04.2 LTS VM in bridged mode.

I'm connecting to an 802.1X based network (eduroam) and this time I can DHCP the VM and receive a different IP address to the host machine, so no address clash there (although the clash was what was reported to us at the time).

However, the VM fails to communicate with the network (I can't ping the gateway or otherwise communicate).

Looking at the DHCP request in the VM (using tcpdump at the Linux shell), the messages go out with the source MAC address of the packet being the virtual MAC of the VM and the client MAC address in the DHCP request itself being the same.

Looking at the DHCP request grabbed on the host (from Wireshark), they have a source MAC address being that of the burned-in address of the real wireless card but with the client MAC address of the VM in the DHCP request itself.

Our DHCP server will then happily give out a different IP address to the VM and the VM picks this up and configures it.  However, it then gets no communication with the wireless network.

In the rest of the capture, all the traffic from the virtual machine is going out of the host adapter with the MAC address of the host machine.

Looking in the user-table on the Aruba controller, there is an entry for the host machine, when searching for it by username, MAC address or IP address.

However, there is no entry for the virtual machine, making me think it hadn't actually started a session for traffic to be allowed, which is why everything was being blocked.

I'm not sure if this has changed since I last looked, when running VMware 5.x, or if the capture from the host is incorrect somehow (I don't really see how the virtual machine can send out traffic with the host machine as the source MAC address as the host wouldn't know which traffic was destined for the VM vs the host, so I'm not sure if this test is correct.

However, having the source MAC address of frame being different from the client MAC address in the DHCP packet being different is certainly something that DHCP Snooping can reject (as it suggests things being spoofed).  However, that the DHCP requests are getting through might suggest this isn't be blocked here but later one, when ARP and IP source addresses are being checked.

I'll do some more tests to see if I can get the duplicate IP address problem with VirtualBox...

OK - very strange: with bridged networking, VirtualBox gets stuck at the DHCPOFFER stage and never does a REQUEST or an ACK or get an IP address.  This would fit with the MAC address of the source going out with the wrong MAC address (as it never makes it back to the VM), but this is also the case with VMware host.

I think I need to do a capture of traffic from the upstream network, before things hit the router (our DHCP server and router are NOT the Aruba controllers: they just act as bridges).  This is awkard as I'm now in a different building.  ;)

However, in the meantime, I've attached pcaps from the host machine of VMware 6.0.0 and VirtualBox 4.2.18, if someone can spot the difference!

Either way, I don't get a duplicate address any more, but it doesn't work!

are you still running an AOS 6.2 variant Bob?

I'm running 6.2.1.2, which is the version recommended by our integrator and I think is a mainstream release.  We had to go to 6.2 in prepration for migrating from 6000+M3 local controllers to 7220s (which run a minimum of 6.2).

I see there is 6.2.1.3 which we could migrate to, but I'd like to get onto the 7220s first - 6.2.1.3 looks like it fixes one problem we've seen (on 6.2 and 6.1) where the local controllers report an AP that's up but the masters report it down.

On the subject of DHCP again, I did some sniffing on my home wireless network last night (which is not Aruba and has no "enforce-dhcp" option!) and observed the same thing:

• a VMware or VirtualBox VM running with bridged networking onto a wireless network sends out all its frames with the MAC address of the host computer;
• however, when running the same same VM on wired networking, it uses the virtual MAC address of the VM

Both of these work fine on my home consumer network and makes me think that VMware must be doing something clever with wireless bridged networking, perhaps intercepting traffic at layer 3 and forwarding it to the appropriate machine (host or virtual).

So this would make me think that the difference between the source MAC of the packet vs the DHCP client MAC address has some effect.  On a Cisco IOS switch with DHCP snooping they will be dropped if they mismatch by default - this can be changed with "no

We're having the exact same issue here.  Aruba support is stumped.  We're not using the enforce-dhcp option.

Was this ever solved?

---

@Ryan wrote:

Was this ever solved?

---

Only in the sense that it works the way I described, in my experience (I haven't tested things since I wrote that).

I haven't tried to find out why Parallels and VMware work differently, nor try to get VMware to work in bridge mode: we've just told people to use NAT mode.  No one has grumbled about that, so we've not looked further.

Please see the post here:  http://community.arubanetworks.com/t5/Unified-Wired-Wireless-Access/DHCP-over-wireless-bridge/m-p/147688#M31433

Thx, disabling arp broadcast filtering did the trick for me. Been trying to solve this one forever!

PERFECT!! Did it for me 2!!