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

Unanswered Question
Aug 7th, 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

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 0 (0 ratings)
Nachtfalkeaw Thu, 08/09/2012 - 13:10

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.

21474833952012-Aug-09 21:40:05Informational %SEC-I-PORTAUTHORIZED: Port gi8 is Authorized       
21474833962012-Aug-09 21:38:23Warning %SEC-W-SUPPLICANTUNAUTHORIZED: MAC 00:19:99:0b:8d:b3 was rejected on port gi8        
21474833972012-Aug-09 21:38:23Warning %SEC-W-PORTUNAUTHORIZED: Port gi8 is unAuthorized       
21474833982012-Aug-09 21:16:05Informational %SEC-I-PORTAUTHORIZED: Port gi8 is Authorized       
21474833992012-Aug-09 21:13:42Warning %SEC-W-SUPPLICANTUNAUTHORIZED: MAC 00:19:99:0b:8d:b3 was rejected on port gi8        
21474834002012-Aug-09 21:13:42Warning %SEC-W-PORTUNAUTHORIZED: Port gi8 is unAuthorized       
21474834012012-Aug-09 21:04:04Informational %SEC-I-PORTAUTHORIZED: Port gi8 is Authorized       
21474834022012-Aug-09 21:03:50Warning %SEC-W-SUPPLICANTUNAUTHORIZED: MAC 00:19:99:0b:8d:b3 was rejected on port gi8        
21474834032012-Aug-09 21:03:50Warning %SEC-W-PORTUNAUTHORIZED: Port gi8 is unAuthorized       
21474834042012-Aug-09 20:52:02Informational %SEC-I-PORTAUTHORIZED: Port gi8 is Authorized       
21474834052012-Aug-09 20:49:02Warning %SEC-W-SUPPLICANTUNAUTHORIZED: MAC 00:19:99:0b:8d:b3 was rejected on port gi8        
21474834062012-Aug-09 20:49:02Warning %SEC-W-PORTUNAUTHORIZED: Port gi8 is unAuthorized       
21474834072012-Aug-09 20:40:04Informational %SEC-I-PORTAUTHORIZED: Port gi8 is Authorized       
21474834082012-Aug-09 20:39:10Warning %SEC-W-SUPPLICANTUNAUTHORIZED: MAC 00:19:99:0b:8d:b3 was rejected on port gi8        
21474834092012-Aug-09 20:39:10Warning %SEC-W-PORTUNAUTHORIZED: Port gi8 is unAuthorized       
21474834102012-Aug-09 20:16:06Informational %SEC-I-PORTAUTHORIZED: Port gi8 is Authorized       
21474834112012-Aug-09 20:14:29Warning %SEC-W-SUPPLICANTUNAUTHORIZED: MAC 00:19:99:0b:8d:b3 was rejected on port gi8        
21474834122012-Aug-09 20:14:29Warning %SEC-W-PORTUNAUTHORIZED: Port gi8 is unAuthorized       
21474834132012-Aug-09 19:28:01Informational %SEC-I-PORTAUTHORIZED: Port gi8 is Authorized       
21474834142012-Aug-09 19:25:08Warning %SEC-W-SUPPLICANTUNAUTHORIZED: MAC 00:19:99:0b:8d:b3 was rejected on port gi8        
21474834152012-Aug-09 19:25:08Warning %SEC-W-PORTUNAUTHORIZED: Port gi8 is unAuthorized       
21474834162012-Aug-09 19:15:59Informational %SEC-I-PORTAUTHORIZED: Port gi8 is Authorized       
21474834172012-Aug-09 19:15:16Warning %SEC-W-SUPPLICANTUNAUTHORIZED: MAC 00:19:99:0b:8d:b3 was rejected on port gi8        
21474834182012-Aug-09 19:15:16Warning %SEC-W-PORTUNAUTHORIZED: Port gi8 is unAuthorized       
21474834192012-Aug-09 19:04:00Informational %SEC-I-PORTAUTHORIZED: Port gi8 is Authorized       
21474834202012-Aug-09 19:00:27Warning %SEC-W-SUPPLICANTUNAUTHORIZED: MAC 00:19:99:0b:8d:b3 was rejected on port gi8        
21474834212012-Aug-09 19:00:27Warning %SEC-W-PORTUNAUTHORIZED: Port gi8 is unAuthorized       
21474834222012-Aug-09 18:27:59Informational %SEC-I-PORTAUTHORIZED: Port gi8 is Authorized       
21474834232012-Aug-09 18:25:55Warning %SEC-W-SUPPLICANTUNAUTHORIZED: MAC 00:19:99:0b:8d:b3 was rejected on port gi8        
21474834242012-Aug-09 18:25:55Warning %SEC-W-PORTUNAUTHORIZED: Port gi8 is unAuthorized    

Any ideas ?

Nachtfalkeaw Mon, 08/13/2012 - 00:18

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 Mon, 08/13/2012 - 09:14

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

-Tom

Nachtfalkeaw Mon, 08/13/2012 - 14:01

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 Tue, 08/14/2012 - 03:24

Hi Tom,

unfortunately it doesn't solve the problem:

21474836182012-Aug-14 12:22:33Informational %AAA-I-CONNECT: New https connection for user HPA, source 172.17.0.10 destination 172.17.240.20 ACCEPTED       
21474836192012-Aug-14 12:19:30Informational %SEC-I-PORTAUTHORIZED: Port gi8 is Authorized       
21474836202012-Aug-14 12:14:22Warning %SEC-W-SUPPLICANTUNAUTHORIZED: MAC 00:19:99:0b:8d:b3 was rejected on port gi8        
21474836212012-Aug-14 12:14:22Warning %SEC-W-PORTUNAUTHORIZED: Port gi8 is unAuthorized       
21474836222012-Aug-14 11:55:29Informational %SEC-I-PORTAUTHORIZED: Port gi8 is Authorized       
21474836232012-Aug-14 11:49:42Warning %SEC-W-SUPPLICANTUNAUTHORIZED: MAC 00:19:99:0b:8d:b3 was rejected on port gi8        
21474836242012-Aug-14 11:49:42Warning %SEC-W-PORTUNAUTHORIZED: Port gi8 is unAuthorized       
21474836252012-Aug-14 11:35:35Informational %SEC-I-PORTAUTHORIZED: Port gi8 is Authorized       
21474836262012-Aug-14 11:34:53Warning %SEC-W-SUPPLICANTUNAUTHORIZED: MAC 00:19:99:0b:8d:b3 was rejected on port gi8        
21474836272012-Aug-14 11:34:53Warning %SEC-W-PORTUNAUTHORIZED: Port gi8 is unAuthorized       
21474836282012-Aug-14 11:11:35Informational %SEC-I-PORTAUTHORIZED: Port gi8 is Authorized       
21474836292012-Aug-14 11:10:13Warning %SEC-W-SUPPLICANTUNAUTHORIZED: MAC 00:19:99:0b:8d:b3 was rejected on port gi8        
21474836302012-Aug-14 11:10:13Warning %SEC-W-PORTUNAUTHORIZED: Port gi8 is unAuthorized       

Any other ideas ?

Tom Watts Tue, 08/14/2012 - 08:38

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

Nachtfalkeaw Tue, 08/14/2012 - 12:14
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:

21474835622012-Aug-14 17:24:58Informational %LINK-I-Up:  gi8       
21474835632012-Aug-14 17:24:56Warning %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 Tue, 08/14/2012 - 13:13

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

Nachtfalkeaw Tue, 08/14/2012 - 13:51

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 Tue, 08/14/2012 - 14:17

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

Nachtfalkeaw Wed, 08/15/2012 - 06:10

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 Wed, 08/22/2012 - 14:08

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 Wed, 08/22/2012 - 15:08

This is another curious and interesting thing:

radius reports this (pay attention of the time):

Aug 22 23:58:46radiusd[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:46radiusd[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:

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

Or this here on the radius:

Aug 22 23:18:30radiusd[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:30radiusd[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:

21474835032012-Aug-22 23:18:30Informational %SEC-I-PORTAUTHORIZED: Port gi8 is Authorized       
21474835042012-Aug-22 23:15:13Warning %SEC-W-SUPPLICANTUNAUTHORIZED: MAC 00:1d:73:7f:19:63 was rejected on port gi8        
21474835052012-Aug-22 23:15:13Warning %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 Wed, 08/29/2012 - 01:53

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!

Actions

Login or Register to take actions

This Discussion

Posted August 7, 2012 at 1:20 PM
Stats:
Replies:14 Avg. Rating:
Views:2912 Votes:0
Shares:0

Related Content

Discussions Leaderboard