SG300-28 Firmware 1.1.2.0 - Dynamic VLAN+freeRADIUS -> Client ge

Nachtfalkeaw · ‎08-07-2012

Hello ladies and gentlemen,

I am using several SG300-28 Switches with firmware version 1.1.2.0.
I have dynamic VLAN enabled. As RADIUS server I am using freeradius 2.1.12.
Authentication is only based on the MAC address. (I configured that on the switches)
On the switches I created three VLANs. VLAN100 for the authenticated clients, VLAN200 for Management interface and VLAN300 as Guest VLAN. After a wrong authentication the clients should be put into this Guest VLAN immediately (I configured this on the switches).
I am using Windows XP and Windows 7 clients in my network. I did not configure any EAP settings because I just wnat to use the MAC address.

In most cases the dynamic VLAN assignment and authentication is working fine. The switch log says that the client is authenticated and the same I can see on freeradius log. But in some (rare) cases the client is rejected. The CISCO log says "MAC aa:bb:cc:dd:ee:ff was rejected on port ge17" but when I look at the freeradius log then this MAC address was successfully authorized.

The problem is that the client gets an IP address based on the Guest VLAN300 but after that the switch seems to "switch" the VLAN on the port and then the client is authenticated correctly on the right VLAN but the client does not request a new IP on the new VLAN.

If I unplug and re-plug the LAN cable in most cases the client get the correct VLAN and the correct IP.

This is happening randomly on nearly all my PCs.

I would really appreciate your help. Do I have to set some timers higher ? I don't think it is a problem between switch and RADIUS but a problem between communication of the host and the switch.

Thank you very much for your help!

Regrads

Alexander Wilke

Nachtfalkeaw · ‎08-09-2012

This is from my CISCO log. The computer is always online but there are repeatingly rejects and then with a delay of some minutes an accept.

2147483395	2012-Aug-09 21:40:05	Informational	%SEC-I-PORTAUTHORIZED: Port gi8 is Authorized
2147483396	2012-Aug-09 21:38:23	Warning	%SEC-W-SUPPLICANTUNAUTHORIZED: MAC 00:19:99:0b:8d:b3 was rejected on port gi8
2147483397	2012-Aug-09 21:38:23	Warning	%SEC-W-PORTUNAUTHORIZED: Port gi8 is unAuthorized
2147483398	2012-Aug-09 21:16:05	Informational	%SEC-I-PORTAUTHORIZED: Port gi8 is Authorized
2147483399	2012-Aug-09 21:13:42	Warning	%SEC-W-SUPPLICANTUNAUTHORIZED: MAC 00:19:99:0b:8d:b3 was rejected on port gi8
2147483400	2012-Aug-09 21:13:42	Warning	%SEC-W-PORTUNAUTHORIZED: Port gi8 is unAuthorized
2147483401	2012-Aug-09 21:04:04	Informational	%SEC-I-PORTAUTHORIZED: Port gi8 is Authorized
2147483402	2012-Aug-09 21:03:50	Warning	%SEC-W-SUPPLICANTUNAUTHORIZED: MAC 00:19:99:0b:8d:b3 was rejected on port gi8
2147483403	2012-Aug-09 21:03:50	Warning	%SEC-W-PORTUNAUTHORIZED: Port gi8 is unAuthorized
2147483404	2012-Aug-09 20:52:02	Informational	%SEC-I-PORTAUTHORIZED: Port gi8 is Authorized
2147483405	2012-Aug-09 20:49:02	Warning	%SEC-W-SUPPLICANTUNAUTHORIZED: MAC 00:19:99:0b:8d:b3 was rejected on port gi8
2147483406	2012-Aug-09 20:49:02	Warning	%SEC-W-PORTUNAUTHORIZED: Port gi8 is unAuthorized
2147483407	2012-Aug-09 20:40:04	Informational	%SEC-I-PORTAUTHORIZED: Port gi8 is Authorized
2147483408	2012-Aug-09 20:39:10	Warning	%SEC-W-SUPPLICANTUNAUTHORIZED: MAC 00:19:99:0b:8d:b3 was rejected on port gi8
2147483409	2012-Aug-09 20:39:10	Warning	%SEC-W-PORTUNAUTHORIZED: Port gi8 is unAuthorized
2147483410	2012-Aug-09 20:16:06	Informational	%SEC-I-PORTAUTHORIZED: Port gi8 is Authorized
2147483411	2012-Aug-09 20:14:29	Warning	%SEC-W-SUPPLICANTUNAUTHORIZED: MAC 00:19:99:0b:8d:b3 was rejected on port gi8
2147483412	2012-Aug-09 20:14:29	Warning	%SEC-W-PORTUNAUTHORIZED: Port gi8 is unAuthorized
2147483413	2012-Aug-09 19:28:01	Informational	%SEC-I-PORTAUTHORIZED: Port gi8 is Authorized
2147483414	2012-Aug-09 19:25:08	Warning	%SEC-W-SUPPLICANTUNAUTHORIZED: MAC 00:19:99:0b:8d:b3 was rejected on port gi8
2147483415	2012-Aug-09 19:25:08	Warning	%SEC-W-PORTUNAUTHORIZED: Port gi8 is unAuthorized
2147483416	2012-Aug-09 19:15:59	Informational	%SEC-I-PORTAUTHORIZED: Port gi8 is Authorized
2147483417	2012-Aug-09 19:15:16	Warning	%SEC-W-SUPPLICANTUNAUTHORIZED: MAC 00:19:99:0b:8d:b3 was rejected on port gi8
2147483418	2012-Aug-09 19:15:16	Warning	%SEC-W-PORTUNAUTHORIZED: Port gi8 is unAuthorized
2147483419	2012-Aug-09 19:04:00	Informational	%SEC-I-PORTAUTHORIZED: Port gi8 is Authorized
2147483420	2012-Aug-09 19:00:27	Warning	%SEC-W-SUPPLICANTUNAUTHORIZED: MAC 00:19:99:0b:8d:b3 was rejected on port gi8
2147483421	2012-Aug-09 19:00:27	Warning	%SEC-W-PORTUNAUTHORIZED: Port gi8 is unAuthorized
2147483422	2012-Aug-09 18:27:59	Informational	%SEC-I-PORTAUTHORIZED: Port gi8 is Authorized
2147483423	2012-Aug-09 18:25:55	Warning	%SEC-W-SUPPLICANTUNAUTHORIZED: MAC 00:19:99:0b:8d:b3 was rejected on port gi8
2147483424	2012-Aug-09 18:25:55	Warning	%SEC-W-PORTUNAUTHORIZED: Port gi8 is unAuthorized

Any ideas ?

Nachtfalkeaw · ‎08-13-2012

Hallo again,

I tried this with the newest firmware 1.2.7.76 but nothing chaged.

I disabled the energy saving options of the network card of the client but no change.

It seems like the switch is not sending the authentication packets to the RADIUS server.

I found out that if I click "re-authenticate" on the port setting on the switch that in most cases the authentication fails and the RADIUS server gets no response from the switch.

Thank you very much for your attention!

Alexander Wilke

Tom Watts · ‎08-13-2012

Hello Alexander, try to change your DHCP lease renew to be more frequent.

-Tom

-Tom Please mark answered for helpful posts http://blogs.cisco.com/smallbusiness/

Nachtfalkeaw · ‎08-13-2012

Hello Tom,

I decreased the lease time from ~3 month to 2 hours.

Will see what happens the next days. Will post any results.

Regards,

Alexander Wilke

Nachtfalkeaw · ‎08-14-2012

Hi Tom,

unfortunately it doesn't solve the problem:

2147483618	2012-Aug-14 12:22:33	Informational	%AAA-I-CONNECT: New https connection for user HPA, source 172.17.0.10 destination 172.17.240.20 ACCEPTED
2147483619	2012-Aug-14 12:19:30	Informational	%SEC-I-PORTAUTHORIZED: Port gi8 is Authorized
2147483620	2012-Aug-14 12:14:22	Warning	%SEC-W-SUPPLICANTUNAUTHORIZED: MAC 00:19:99:0b:8d:b3 was rejected on port gi8
2147483621	2012-Aug-14 12:14:22	Warning	%SEC-W-PORTUNAUTHORIZED: Port gi8 is unAuthorized
2147483622	2012-Aug-14 11:55:29	Informational	%SEC-I-PORTAUTHORIZED: Port gi8 is Authorized
2147483623	2012-Aug-14 11:49:42	Warning	%SEC-W-SUPPLICANTUNAUTHORIZED: MAC 00:19:99:0b:8d:b3 was rejected on port gi8
2147483624	2012-Aug-14 11:49:42	Warning	%SEC-W-PORTUNAUTHORIZED: Port gi8 is unAuthorized
2147483625	2012-Aug-14 11:35:35	Informational	%SEC-I-PORTAUTHORIZED: Port gi8 is Authorized
2147483626	2012-Aug-14 11:34:53	Warning	%SEC-W-SUPPLICANTUNAUTHORIZED: MAC 00:19:99:0b:8d:b3 was rejected on port gi8
2147483627	2012-Aug-14 11:34:53	Warning	%SEC-W-PORTUNAUTHORIZED: Port gi8 is unAuthorized
2147483628	2012-Aug-14 11:11:35	Informational	%SEC-I-PORTAUTHORIZED: Port gi8 is Authorized
2147483629	2012-Aug-14 11:10:13	Warning	%SEC-W-SUPPLICANTUNAUTHORIZED: MAC 00:19:99:0b:8d:b3 was rejected on port gi8
2147483630	2012-Aug-14 11:10:13	Warning	%SEC-W-PORTUNAUTHORIZED: Port gi8 is unAuthorized

Any other ideas ?

Tom Watts · ‎08-14-2012

If I unplug and re-plug the LAN cable in most cases the client get the correct VLAN and the correct IP.

This is happening randomly on nearly all my PCs.

This seems to be the key bit of information. Once you're placed on the guest vlan, the client computer gets an IP address. Once the switch put you to the authenticated vlan, your IP is not updating.

I think if you did a show mac address-table you may find your computer is on the correct VLAN. Now, if it is seen not going to the correct vlan after you authenticate, that is a different issue. The documented bug identifies that you shouldn't remove the VLAN attributes on the RADIUS server. The criteria of that bug indicates the RADIUS does not have the VLAN attributes which should be as following;

IETF 64
IETF 65
IETF 81

Also considering, the VLAN attributes is generally assigned through the credential provided. What happens if you set up the credential with the vlan attributes as desired?

This seems to be more of a client issue and the ability to respond to the new requests. Just out of curiosity, can you set the DHCP lease to lets say, 10 seconds? Can you do an ipconfig/release and ipconfig /renew ?

-Tom

-Tom Please mark answered for helpful posts http://blogs.cisco.com/smallbusiness/

Nachtfalkeaw · ‎08-14-2012

This seems to be the key bit of information. Once you're placed on the  guest vlan, the client computer gets an IP address. Once the switch put  you to the authenticated vlan, your IP is not updating.

Yes, I recognized this behaviour in the past. The minimum lease time of my DHCP is 60 seconds. But you are right. If a client get the guest VLAN instead of the correct one then the client gets an IP in the guest VLAN range - but the switchport seems to dwitch to the correct VLAN some shotr time after that. If I do ipconfig /release and then ipconfig /renew - it took some release-renew - the client gets the correct IP address.

So my question would be - as it seems to be some kind of client problem - that the switch is not changing the VLAN too fast to the guest VLAN so that the client will not get an IP from the wrong VLAN ?

I think if you did a show mac address-table you may find your computer is on the correct VLAN. Now, if it is seen not going to the correct vlan after you authenticate, that is a different issue. The documented bug identifies that you shouldn't remove the VLAN attributes on the RADIUS server. The criteria of that bug indicates the RADIUS does not have the VLAN attributes which should be as following;

IETF 64
IETF 65
IETF 81

You are right, the client is in the correct VLAN. Not sure if the documented bug affects all versions because I had the problem I described in this thread with version 1.0.0.27, 1.1.2.0 and 1.2.7.76.

My users file on the RADIUS sever looks like this:

"0019990b8db3" Cleartext-Password := "0019990b8db3"

Tunnel-Type = VLAN,

Tunnel-Medium-Type = IEEE-802,

Tunnel-Private-Group-ID = "10"

This seems to be more of a client issue and the ability to respond to  the new requests. Just out of curiosity, can you set the DHCP lease to  lets say, 10 seconds? Can you do an ipconfig/release and ipconfig /renew  ?

I am just able to set it to 60 seconds. Is your intention to set the DHCP lease time as low as possible on the guest VLAN so if a client gets first the guest VLAN + IP and the the switch port changes back to the correct VLAN that the client releases and renews its IP and gets the correct one from the new VLAN ?

What is a little bit curious is this log:

2147483562	2012-Aug-14 17:24:58	Informational	%LINK-I-Up: gi8
2147483563	2012-Aug-14 17:24:56	Warning	%LINK-W-Down: gi8

Don't know why the link is going down. No energy options enabled on the switch (disabled globally and per port) and no energy saving on the NIC and no hibernate or standby on the client.

I disabled the EAP service on the client so that there is no possibility that wrong credentials are provided in any way because as I wrote before - I just use the MAC authentication.

And another thing is that most of the hosts which have this problem are running windows XP. I didn't recognize much (or any) problems with Windows 7 clients...

Thank you for helping me even if this is perhaps more a problem of the client and not the switch but I want to be sure that I did all which is possible to get it work correctly.

Tom Watts · ‎08-14-2012

Alexander, on the switch side, you may try to manually specify port fast for the spanning tree interfaces and may be set the bpdu to filter from flooding. This can help out some. But, in the end, I don't think it is a RADIUS issue at all.

Many times in my lab using any computer connecting to a switch with vlans and a dhcp server, if you have a computer on vlan 4 then move it to any other vlan, it will sit there "forever" waiting for the new DHCP.

-Tom

-Tom Please mark answered for helpful posts http://blogs.cisco.com/smallbusiness/

Nachtfalkeaw · ‎08-14-2012

Hi Tom,

I tried with RSTP + BPDU Flooding enabled and (R)STP disabled at all. Nothing changed.

Another question:

When going to SECURITY -> 802.1X -> Properties

There is an Option "Guest VLAN Timeout". At the moment it is set to "Immediate". What is happening if I set this to 180 seconds. Is the switch within these 180 able to get authroized or change its state or is this just a delay which does not affect my problem ?

My intention is - if something is going wrong the first 60 or 120 minutes, no MAC address sent or no VLAN attribute or something else - then the port or host has 180 seconds of time to get a new response from RADIUS server or new credentials from client or the client cannot get any IP from DHCP and so will not "sit" on a wrong IP address. But if it doesn't matter if the port will remain unauthorized in no VLAN for zero seconds or for 180 before going to the guest VLAN because there is nothing which can change the port state within this time this will probably make no sense.

So if you could explain me this option a little bit more in detail or where to use this timer could help me.

Thanks for your time!

Tom Watts · ‎08-14-2012

Alexander,

The guest vlan timeout is implemented as a specified amount of time.

Once this timeout expires, if there is an unauthorized connection, it goes to the guest VLAN. If the port status changes from authorized to not authorized, this will also go to the guest vlan after the time out.

The flow of this connection should be kind of like a hold period. When the link state detects, the guest vlan timeout starts to tick. This alotment should be the point where you are authorized or not before the switch moves you to the default action of assigning the port as guest vlan. With the action immediate, it puts you to the guest vlan asap until you're authorized.

So it may not be a bad idea to assign this value at 30 seconds to give yourself some time to get to the authorized vlan connection or wait 30 seconds to be manually placed on the guest vlan

-Tom

-Tom Please mark answered for helpful posts http://blogs.cisco.com/smallbusiness/

Nachtfalkeaw · ‎08-15-2012

Hi Tom,

thank you for your time and help. But unfortunately nothing didn't help and I do not see any improvement - no matter which setting I changed.

On newer OS versions (Windows 7) it seems to work but not on all Windows XP versions.

Don't know why this is because its just the MAC authentication and this should be independent of the OS - but perhaps it is dependent on the NIC or some settings on the NIC.

If you have other suggestions - please don't hesitate to post them here :-)

Alexander Wilke

Nachtfalkeaw · ‎08-22-2012

Hallo again,

I still didn't found the reason or solution for my problem but two other settings I need some help with:

1.) For what do I need the "Administrative PVID" ? I left this at VLAN1 but I do not use this anywhere. Could it make sense to put it on the same VLAN as the "Guest VLAN" ?

2.) Interfaces Settings -> Port Mode: I tried with the port mode "General" and "Admit all" or "Admit untagged only" and I tried with port mode "Access" only. I don't think it is reliable for my problem if I chose ACCESS or GENERAL but I want to be sure.

Thank you!

Nachtfalkeaw · ‎08-22-2012

This is another curious and interesting thing:

radius reports this (pay attention of the time):

Aug 22 23:58:46	radiusd[26550]: Login OK: [001f3ffc038f/] (from client SG300-28-03 port 57 cli 00-1F-3F-FC-03-8F) Assigned VLAN-ID: 10
Aug 22 23:58:46	radiusd[26550]: Login OK: [001f3ffc038f/] (from client SG300-28-03 port 57 cli 00-1F-3F-FC-03-8F) Assigned VLAN-ID: 10

Amd this is the log of the cisco:

2147483488	2012-Aug-22 23:58:46	Informational	%SEC-I-PORTAUTHORIZED: Port gi9 is Authorized
2147483489	2012-Aug-22 23:58:46	Warning	%SEC-W-SUPPLICANTUNAUTHORIZED: MAC 00:1f:3f:fc:03:8f was rejected on port gi9
2147483490	2012-Aug-22 23:58:46	Warning	%SEC-W-PORTUNAUTHORIZED: Port gi9 is unAuthorized

Or this here on the radius:

Aug 22 23:18:30	radiusd[26550]: Login OK: [001d737f1963/] (from client SG300-28-03 port 56 cli 00-1D-73-7F-19-63) Assigned VLAN-ID: 10
Aug 22 23:18:30	radiusd[26550]: Login OK: [001d737f1963/] (from client SG300-28-03 port 56 cli 00-1D-73-7F-19-63) Assigned VLAN-ID: 10

And this on the cisco:

2147483503	2012-Aug-22 23:18:30	Informational	%SEC-I-PORTAUTHORIZED: Port gi8 is Authorized
2147483504	2012-Aug-22 23:15:13	Warning	%SEC-W-SUPPLICANTUNAUTHORIZED: MAC 00:1d:73:7f:19:63 was rejected on port gi8
2147483505	2012-Aug-22 23:15:13	Warning	%SEC-W-PORTUNAUTHORIZED: Port gi8 is unAuthorized

For me it looks like the cisco is not sending the access-request packets to the RADIUS server.

Any other ideas how to debug this problem any deeper ?

Nachtfalkeaw · ‎08-29-2012

Hello everybody,

I think I have found the problem with the switch. The problem is the "Aging time" of the dynamic MAC addresses learned on the ports. If a client is not busy enough on the network, the MAC address is timing out on the switchport and this forces the switch to unauthenticate the port.

I increased the aging time fromm 300s up to 630s (which is poorly the maximum allowed by the switch) and reduced the DHCP release time to 600s. This causes higher DHCP traffic on the network but forces some quiet clients to talk to the switch/network.

What I think what is buggy on the switch that the switch forgets the MAC address on the port after "aging time" but the link is still up.

A suggestion - correct me if this makes no sense:

1.) Possibility to set the dynamic MAC address "Aging time" higher than 630s. On busy networks with many clients such a low value would make sense. On a network which does not have so many clients - just a few hundreds - it could make sense to be able to cache these entries a longer time. The ARP settings you can set in the "GUI -> IP configuration" allowes you values up to several days of caching time. Why not allowing this for the other MAC address table ?

2.) When using dynamic VLAN assignment + RADIUS you must set the port to "Multiple Session". "Multiple SessioN" only allows maximum 8 MAC addresses per port. So it would make sense if someone connects to the port, the port link comes up, that the switch is remembering the last 8 connected and authorized MAC addresses for an unlimited time UNTIL the port link goes down. If further addresses than 8 needs to be learned than the oldes saved MAC address on this port will be deleted.

I would appreciate any feedback and/or help on how to modify or workaround the low "Aging time".

Thank you!

SG300-28 Firmware 1.1.2.0 and 1.2.7.76 - Dynamic VLAN+freeRADIUS -> Client get rejected