Wireless Access

Hi

Just to let you guys know, and this is confirmed by Aruba TAC.

There is a bug in the 6.3.1.6 software, related to user derivation rules.

The particular customer has a user derivation rule (DHCP fingerprint) in place for iOS devices, placing them in a seperate VLAN.

In 6.3.1.6, this is not done to the specified devices, but for all devices.

All devices that try to connect to a SSID which utilzes the AAA profile with the user derivation rule, will be picked up and placed in the vlan/role of the rule.

This was experienced on a 3400 controller running 6.3.1.6, all works fine on 6.3.1.5.

Mosher

Did they confirm this only happens if it is specifically a dhcp fingerprint rule?

Hi Mosher

Do you know whether this would affect machine authentication?  I am having an issue with one of my customers, we have set up machine authentication to block mobile devices from access the internal network but they still seem to get access. 

Hi guys

The customer in question do have machine authentication setup on the SSID were this derivation rule is used.

The AAA profile for the employee does have the "machine authentication" boxed checked.

The rule in use looks like this

aaa derivation-rules user iOS
  set role condition dhcp-option equals "370103060F77FC" set-value iOS_dummy

Normally it picks up iOS based devices and places them in a different vlan, in my example it's placed in a role, but at the moment its placed in a vlan.

This works great for keeping iOS devices out of the employee network.

With 6.3.1.6, all devices, not only iOS are placed in the VLAN. Hence nobody could use the employee network as all their MAC's and PC's were moved to the iOS vlan.

This is the explanation i got from Aruba TAC.

The reason why it is not working in 6.3.1.6 is that in order to match the rule the controller should go through the list of attributes received form radius server one by one
In this case due to as software defect  in the  logic controller is not going through the entire list hence rule is not matched.

In my head it should have been the other way around. It will match anything, not just the iOS fingerprint.

As opposed to normal behavior, on let's say a HP computer, nothing is matched, computer connects normally and are placed in the correct employee VLAN.

Anyway, it's not working correctly in 6.3.1.6 towards iOS DHCP fingerprint. If this is the case for other fingerprint devices, i do not know.

Mosher

I'm told by another Aruba partner who had the same issue, that this is fixed in 6.3.1.7, though the release notes don't specifically mention about fingerprinting UDR rules. 

Hi

Yeah, i also read the release notes looking for the solution. There was one bug fixed, which i think is related to the problem.

This because the message i got from Aruba TAC was also a bit cryptic and not completely in line with the problem we saw, but something close to the info in the release notes.

Aruba TAC also said that the problem was allready identified and that 6.3.1.7 was to contain the fix. We have not upgraded the customer's Aruba, but i tested the 6.3.1.6 version on our company's Aruba, and i could easily replicate the problem.

I have now upgraded our Aruba to 6.3.1.7, i will test this again.

Roar Fossen

Mosher,

If you have a Case # or bug # we can determine what is at play here and if and when it can be fixed.

Hi

I thought that i did get the bug # from Aruba TAC, but is unable to find it.

Case # is 1534110.

I just did a quick test on our Aruba system, and it seems like the bug is fixed.

The initial problem was that when you added DHCP finterprint , in this case Apple, the controller moved all clients to the new VLAN, not only Apple iOS.

when running 6.3.1.7, the system is working as inteded. My iPAD is moved to a different vlan, according to the rule, but my Android phone is getting an IP in the vlan on the virtual AP.

Roar Fossen

SDR=Server Derivation rule

UDR=User Derivation rule.

Mosher, we found this bug internally before you reported it.  That is why the description has a more general explanation as to what the problem was.

Hi

Yes, that was my understanding aswell, because one of the first mails from Aruba TAC told me it allready was found, with bug # something. It was this number i was looking for yesterday, but could not find.

Anyway, looks as it is fixed in 6.3.1.7, our controller now behaves as it should whn trying this UDR.

Mosher