using aaa authenticator for MAC authentication

[gunnarwb]

I'm already on the phone with HP on this question but so far they have been unable to help me. I'm using NAP (the new IAS) for RADIUS and everything works great using theses commands:

gvrp
aaa authentication port-access eap-radius
radius-server timeout 1
radius-server host 192.168.1.71 key password
aaa port-access gvrp-vlans
aaa port-access authenticator 1-48
aaa port-access authenticator active

however, I would like to setup MAC based authentication as well for devices that don't support 802.1x (EAP) authentication. Now according to HP you can do this under my current setup by just adding a username/password on my Active Directory environment that is equal to MAC Address/MAC Address.

I have tried this but it doesn't work. I have a packet sniffer running on my RADIUS server and if I plug in a non 802-1x device on the ProCurve switch it doesn't even send a packet to the RADIUS server. However, if I change my config and use:

aaa authentication mac-based chap-radius
aaa port-access mac-based 1-48

my MAC authorization starts to work but my 802.1x fails (for clients that support 802.1x). I have looked at the packets and it looks like the 802.1x is being accepted but the MAC authorization fails, and therefore the port gets moved to an unauth VLAN.

HP says I shouldn't have to use those second commands and that everything should work under the config I posted, but the switch isn't sending any packets when I use it that way.

Can anyone point me in the right direction?

[Jeff Carrell]

well, i have experienced basically the same results you have...altho i haven't done my vlans via GVRP...

if you try to do mac auth and regular 802.1X auth on same port, mac auth takes precedence...and you can never get successful 802.1X auth to work...

this was supposed to be fixed awhile ago on later K.12.xx code (provision asic only switches), but i have not seen it work yet...but i have not tried it lately on later K.12, nor K.13/K.14 code to see...

and i would not think that mac auth would work at all without telling the switch to look at and pass the mac addr on, so 'mac-auth' would be needed...

i know i didn't really have an answer to your issue, but i wanted to comment that the issue has been around for awhile...

obtw, same scenario exists for 802.1X/web auth simultaneous config on a port...

hth...jeff

[gunnarwb]

Yeah I was on the phone with HP for days and they ended up telling me it wasn't supported, which was bogus because I've seen articles explaining exactly how to set it up on a 2650. I was able to get it to work, I had to add a couple commands in there:

aaa port-access authenticator <> quiet-period 30
aaa port-access authenticator <> client-limit 1
aaa port-access mac-based <> logoff-period 862400
aaa port-access mac-based <> quiet-period 30

The client-limit line was the most important, once I put that in there MAC and 802.1x worked at the same time. I have no idea what that line means but I'll take it.

Too bad HP support was worthless.

[Arran Cudbard-Bell]

The 802.1X authenticator can operate in two modes:
Port-Base and Client-Based.

In Port-Based mode (no client-limit), the entire port is either in the authorised or unauthorised state. When it's authorised, any packet ingressing from any client is forwarded, and in the unauthorised state all non EAPOL packets are dropped.

In Client-Based mode (client-limit set), the port maintains a filtering table, only allowing packets from authenticated devices to ingress.Client-Based mode also allows for multiple 802.1X sessions to take place.

So say you have an environment with a repeating hub connected to 5 workstations and an 802.1X authenticated port. With port-based mode, only one workstation would need to authenticated for all workstations to gain connectivity. With client-based mode each individual workstation would need to authenticate.

If you're following the 802.1X spec to the letter, an unauthorised port can only allow EAPOL frames to ingress, with all other traffic being dropped (before the Mac authenticator has a chance to process it).

Client-Based mode is an extension of the standard it's ~802.1X but doesn't follow it as rigidly. In this mode it would appear that normal packets are processed by the Mac-Authenticator even when the port is in an unauthorised state.

The 2610 ASG says 802.1X (Port-Based) + WMA is not recommended, and the latest from Roseville is that it's not supported.