Wired Intelligent Edge

Hi all,

I've got a location with Aruba 2920-48G switches. These switches run the latest WB.16.02 firmware. I've configured Port-access on all the switches, so that each port has to authenticate first with our Clearpass server.

The following now happens:

When a laptop connects with the port, it authenticates itself and than gets assigned VLAN xx. Next, a VOIP phone is connected to the same port (using a unmanaged switch) and this device also authenticates and should receive VLAN YY. This last part is not working. The device does not get an IP.

This made me think because in the HPE ArubaOS-Switch Access Security Guide for WB.16.02 states the following:

MAC-Based VLANs (MBVs) allow multiple clients on a single switch port to receive different untagged VLAN assignments. VLAN assignment of untagged traffic is based on the source MAC address rather than the port. Clients receive their untagged VLAN assignment from the RADIUS server. 

What am i missing in this configuration? (i tried to copy everything related for this question:

aaa authentication port-access eap-radius server-group "clearpass" cached-reauth
aaa authentication mac-based chap-radius server-group "clearpass" cached-reauth
aaa port-access mac-based 1-30
aaa port-access mac-based 1 addr-limit 32
aaa port-access mac-based 1 addr-moves
aaa port-access mac-based 1 reauth-period 86400
aaa port-access mac-based 1 unauth-vid XX
aaa port-access mac-based 1 cached-reauth-period 86400
aaa port-access authenticator 1-30
aaa port-access authenticator 1 reauth-period 86400
aaa port-access authenticator 1 client-limit 10
aaa port-access authenticator 1 cached-reauth-period 86400

Running configuration:

interface 1
untagged vlan 4092
aaa port-access authenticator
aaa port-access authenticator reauth-period 86400
aaa port-access authenticator client-limit 10
aaa port-access authenticator cached-reauth-period 86400
aaa port-access mac-based
aaa port-access mac-based addr-limit 32
aaa port-access mac-based addr-moves
aaa port-access mac-based reauth-period 86400
aaa port-access mac-based unauth-vid XX
aaa port-access mac-based cached-reauth-period 86400
spanning-tree admin-edge-port
spanning-tree bpdu-protection
loop-protect
exit

Extra info:

The different YY and XX vlans work perfect when configured statically. So there is no DHCP issue etc. 

The 4092 vlan is a dummy and does not allow any form of network. 

Hello, yes i checked that document, but i could not find anything that would explain the behaviour that im seeing. 

Are you pointing at something particularly? 

i just double checked, the only thing missing is the user-roles etc. we just use port-access. 

1. Are the devices authenticated and working in their right VLAN and getting the right IP if you plug them directly into the switch port without any hub in between? Just to check if the devices will get the right VLAN assigned by the RADIUS Server.
2. As I see that you also have “unauth-vid xx” configured you should know that by default, unauthenticated clients on the Unauth VLAN are disconnected with MBV when a client authenticates to the port. If you want, however, you can enable mixed-mode authentication, which allows unauthenticated clients to connect in the Unauth VLAN and authenticated clients to connect in their assigned VLANs.

Sorry, i was sick for a few days, so couldn't react.

i will check this next wednesday and check point 2 of your comment :)

Ok, status update.

I've got a port thats connected with a unmanaged switch (thats on the table of the users.)

On this switch, there are a couple of voip phones connected that are mac-authenticated to vlan 30 and also get a IP adres in vlan 30. Next, a user plugs in his laptop and Clearpass acknowledges the laptop and gives back the following repsonse :

So the computer should be allowed in VLAN 16, but it never receives an IP adres in this VLAN and i also dont see it with vlan 16 in 'show port-access clients'. 

I enabled the mixed, as you said, but that does not solve it. 

Hello, lets give a status update of what i found and so.

So last week i've re-enabled the functionality of mac-based vlans and i was able to do a wireshark trace on one of the computers that was having troubles.

i found out that 802.1x is working fine. Every device is accepted in clearpass and i also see this in the wireshark trace. The problem is that no device gets a DHCP lease. It just gets a 169. address and doesnt do a DHCP request or anything like that (no initial broadcast).

But when i place the computer in that VLAN by hand, it will get a dhcp lease.

Any ideas about this? tested on a Windows 10 machine. 

Hello,

it's been a time before i had time to really look into this problem. i found the following issue.

For my explanation, i will use port 29.

Port 29 has the following config:

interface 29
   untagged vlan 16
   aaa port-access authenticator
   aaa port-access authenticator server-timeout 30
   aaa port-access authenticator reauth-period 86400
   aaa port-access authenticator client-limit 10
   aaa port-access authenticator cached-reauth-period 86400
   aaa port-access mac-based
   aaa port-access mac-based addr-limit 32
   aaa port-access mac-based addr-moves
   aaa port-access mac-based reauth-period 86400
   aaa port-access mac-based cached-reauth-period 86400
   spanning-tree admin-edge-port
   spanning-tree bpdu-protection
   loop-protect
   exit

port 29 is connected with a unmanaged HP 1420-8G switch that stands on a desk. 

when i connect one laptop, its 802.1x authenticated. when i add a phone, its mac authenticated and if a add another laptop, all goes well.

When i disable port 29 and re-enable it, all goes well.

When i power off the switch (the HP1420) and power it on, then all goes wrong. The laptop gets placed in a VLAN for mac-authenticated devices, but the laptop also successfully authenticates the 802.1x authentication, but never gets placed in that VLAN. After 30 seconds, the laptop retries to authenticate with 802.1x and succeeds, but still stays in the mac-authenticated VLAN. 

the re-authenticate is forced by the following command:

aaa port-access authenticator 29 tx-period 30

if i put this to 100, then the 802.1x authentication happens every 100 seconds.

Extra info:

802.1x authentication places the laptop in VLAN 16 with a IP range specific for that range.

MAC authentication places the laptop in VLAN 24 with a IP range specific for that range.

throughout the test i was able to ping the laptop on the IP that is used for mac-authentication. The ping timed-out once when a re-authenticate happens. 

The switch has a latency of 120 with the ClearPass radius server.

i've got no idea whats wrong with this configuration and every help is much appreciated. 

I'm stuck at the same place as you are. I just posted a new post here without noticing your post here. I don't have the un-managed switch like you are but it is still not working. I've done this setup multiple times with Cisco or Juniper switches and it is WELL documented out there.

See:  https://support.hpe.com/hpsc/doc/public/display?docId=a00038755en_us 

(page 219)

See:  https://support.hpe.com/hpsc/doc/public/display?docId=a00038755en_us 

(page 219)

I finally found the problem a couple of weeks ago, but didnt have the time to respond. Thanks for your link, but my problem was something different.

On one day, i enabled full debugging on the switch, which (ofcourse) gave me tons of information. when i filtered on the mac-address i saw one little line that pushed me in the right direction. 

We've one accesspoint with 2 network cables. One is a uplink for the accesspoint, but the other functions as a guest network. in short, when 802.1x fails and mac-auth fails, you'll be placed in the vlan that gives guest-access. This is configured on the second port of the AP and somehow the AP had some sort of bridge mode active. So the mac-address that was failing, was first seen on the 802.1x port, but 2 seconds later also on the second port of the AP. This then bounced like this for the rest of its lifetime :(

when i disabled that second port, everything worked like it should. So i did some changes on the accesspoint and after that, all was ok and 802.1x is now working fine.