Security

For reference this follows the progression from Radius assigned VLAN on AP-93H wired ports

When using a radius server to handle MAC authentication requests for clients on the wired ports of the AP-93H the clients MAC address isn't passed to the radius server each time they connect their ethernet cable.

Tests I've done:

Test 1:

• Set VLAN for computer in radius server
• plug computer in and get IP address
• change VLAN for computer in radius server
• unplug computer and plug back in (waiting 5 seconds in between)
• This works correctly provided I don't do anything else on the computer other than get an IP address

Test 2:

• Set VLAN for computer in radius server
• plug computer in and get IP address
• surf the internet for > 60 seconds
• change VLAN for computer in radius server
• unplug computer and plug back in (waiting 5 seconds in between)
• computer still gets previous VLAN and IP

Test 3:

• Set VLAN for computer in radius server
• plug computer in and get IP address
• surf the internet for > 60 seconds
• change VLAN for computer in radius server
• unplug for an extended period of time or just wait for a while and then wait longer
• computer gets moved to new vlan

The issue:

We use MAC based registration to map users to computers so when a user plugs in and the radius server doesn't recognize them it drops them on a VLAN which is only for registration.  After the user goes through the web based registration they reboot their computer and get put on a valid VLAN.  This works on all our Procuve switches as they don't cache logins and only need a brief < 1 second of the network card being off to cause the port to go back into authentication mode.

Please use the "show auth-tracebuf" command when the client is plugged in to see the exact radius traffic going back and forth.

In addition, you can also remove the user from the user-table with the "aaa user delete mac <mac address>" command before plugging it back into the AP to clear any sessions.

I've been watching my radius server in debug mode to see what communication is going on.  I've had a laptop plugged in for a while now and doing a 

     show auth-tracebuf mac d8:d3:85:0a:1a:0c

displays nothing as does 

     show auth-tracebuf | include d8:d3:85:0a:1a:0c

Even after unplugging the laptop and plugging it back in.

Doing a "show log all | include d8:d3:85:0a:1a:0c"gives me lots of lines with the following

Jul 12 14:16:11  authmgr[1623]: <522035> <INFO> |authmgr|  MAC=d8:d3:85:0a:1a:0c Station UP: BSSID=01:80:c2:00:00:03 ESSID=n/a VLAN=13 AP-name=AP93HTest

But if I plug in a new device the above commands all show information.

I don't seem to have an "aaa user delete" command under configure terminal, is it located elsewhere?

you should be in exec mode (#) to "use aaa user delete"

---

@ncuit wrote:

I've been watching my radius server in debug mode to see what communication is going on.  I've had a laptop plugged in for a while now and doing a 

     show auth-tracebuf mac d8:d3:85:0a:1a:0c

displays nothing as does 

     show auth-tracebuf | include d8:d3:85:0a:1a:0c

Even after unplugging the laptop and plugging it back in.

 

Doing a "show log all | include d8:d3:85:0a:1a:0c"gives me lots of lines with the following

 

Jul 12 14:16:11  authmgr[1623]: <522035> <INFO> |authmgr|  MAC=d8:d3:85:0a:1a:0c Station UP: BSSID=01:80:c2:00:00:03 ESSID=n/a VLAN=13 AP-name=AP93HTest

 

 

But if I plug in a new device the above commands all show information.

 

 

I don't seem to have an "aaa user delete" command under configure terminal, is it located elsewhere?

---

Hold on, are you doing 802.1x or are you just doing mac authentication?

If you are just doing mac authentication,  you cannot switch the VLAN of a wired client through mac authentication.  That is because the client, as soon as the interface comes up, sends a DHCP request on the primary VLAN before the mac authentication fires and switches the VLAN.  Even if the VLAN is switched internally, the client's link would have to go down, then up to request DHCP again, to switch VLANs.

This would only be possible with wired 802.1x

I'm doing MAC-auth and DHCP requests are working fine. 

I'm also doing a release/renew of my DHCP just in case. 

Sure the first DHCP request might fall on deaf ears, but the second request should follow a few seconds after, so far in my tests however it appears that the first DHCP request is getting responded to correctly.

Allright. 

If a wired device is still in the user table, no mac authentication will be performed again even if you unplug it then plug it in again.

You need to use the aaa user delete or "disconnect" to remove it.

I did try aaa user delete and that worked, but there is no way I'm going to do that for every student that wants to use a wired port.

Any other ideas or do I just tell users to register and then unplug for a few hours and then try again?

Yes I know, 802.1X is the ultimate solution for this, unfortunately Xbox, PS3, Wii, AppleTV....don't have 802.1X supplicants.

---

@ncuit wrote:

I did try aaa user delete and that worked, but there is no way I'm going to do that for every student that wants to use a wired port.

 

Any other ideas or do I just tell users to register and then unplug for a few hours and then try again?

 

Yes I know, 802.1X is the ultimate solution for this, unfortunately Xbox, PS3, Wii, AppleTV....don't have 802.1X supplicants.

---

I mentioned wired 802.1x because it works with regards to wired VLAN switching.  With your current setup If the user unplugs for 6 minutes, they should be removed from the table and it will work in that situation, and that might be acceptable to you.

I do not know the entire scope of what you want to do, so I can only advise you about this issue.  I know that you should have as many devices connected wirelessly as possible and leave wired for the incapable devices, because wireless is much more flexibile.  if you are forced to do wired stuff, make the default VLAN the VLAN that non-intelligent devices would end up in and then save the wired 802.1x switching for clients that can support it.

I'm not sure I can get people to actually wait 6 minutes, and I'm guessing there isn't a way to lower that wait time and even if there were it's probably a really bad idea.

Thanks for the help, I'll see what I can come up with from here.

There may be another way.  What is the current registration workflow?

Not sure how indepth you want, sort of a high level overview would be

New computer plugs in

Computer gets put on "unkown device" VLAN

"unkown device" VLAN forces all traffic to web based registration system that asks for username/password

Web based registration system grabs users IP and looks up associated MAC address in dhcp leases table

MAC address gets stored in database for radius server

User gets web page tell them to reboot their computer and facebook will work

User reboots computer and gets put on the approriate VLAN based on their credentials

For things without a web browser, we have website that users can go to and enter the mac address of the device needing access

What is your radius server?

freeradius

Having this run upon a user going through network registration seems to work well enough, have to see how well it scales this fall.

#!/usr/bin/expect
set key [lrange $argv 0 0]
spawn ssh admin@controller.company.com
expect "*?assword*"
send -- "yourPassword\r"
send -- "\r"
expect "*>"
send "enable\r"
expect "Password:"
send "yourEnablePassword\r"
expect "(Sunset) #"
send "aaa user delete mac $key\r"
expect "*users deleted"
send "exit\r"
expect "*>"
send "logout\r"
expect eof

Great idea.

Let us know how it works.

I'm following behind you with PacketFence...

Have you tried RFC3576 Radius CoA yet? It scales better than scripted CLI, and works fine for macauth on the wireless side.

As with wireless, MacOS doesn't necessarily re-DHCP upon loss of link. Set your unregistered lease time accordingly.

I pulled up tRFC3576 up to read, but I haven't had a chance to look at it yet.  It excites me when actual RFC's get referenced.

As a cheat sheet, this will make the Aruba controller forget the association, for both wired and wireless clients:

printf "NAS-IP-Address=$controller
Calling-Station-Id=$mac
" | radclient -x $controller:3799 disconnect $radsecret

(In my testing, MAC address is case-insensitive, and accepted with or without colons/dashes.)

However, this still doesn't solve the problem of clients holding on to DHCP leases. We'll still have to tell clients to reboot or unplug for a new VLAN. Ideally, we'd flap link on the port.