Not rejecting rejected users
Hi all, Possibly a ridiculous question, but I'll try anyway. We have freeradius running for wired and wireless clients. On wired clients, when the radius sends a reject packet to the NAS, all is well and the client gets rejected. On wireless however, especially with windows XP machines, the machine will constantly retry connection to the SSID. We've dealt with this in the past by hiding the SSID and hoping non-authenticated people try not to join it. This breaks the recommendations I believe, and causes certain issues with ipads and so on, so I wanted to do something different - i.e. dish out a dummy vlan or special role to the wireless controller. No problems there in concept, but we were very geared towards accepts and rejects and I now need to, at several points, do something else instead of outright reject the client. Rejects were nice because once auth-type is set to reject, anything else that could alter the auth-type would not be touched, and lots of extraneous processing is avoided. Ideally we'd be able to change the post-auth-type REJECT back into an accept, but that probably isn't going to work. Anyone any ideas? I'm sure this has been done before. I realise we can override the outcome of a specific module but it doesn't stop processing unless I keep checking an internal control variable or the like. Thanks Andy
Hi,
clients, when the radius sends a reject packet to the NAS, all is well and the client gets rejected. On wireless however, especially with windows XP machines, the machine will constantly retry connection to the SSID.
whats the cause of the reject? incorrect password? you can use the MSCHAPv2 retry method if its PEAP - the client will geta prompt to reenter their credentials...otherwise the client will just keep on trying and trying and trying.... with wireless 802.1X you cannt reject and give them another vlan like you can with wired (*) the key required for the WPA2enterproise part is done in the access-accept . with wired you have guest/fail vlan options (not with MACSEC though). alan (*) some vendors have really interesting/nasty non-interopt kludges to get their APs to do some 'nasty things' in some cases.
participants (2)
-
A.L.M.Buxey@lboro.ac.uk -
Franks Andy (RLZ) IT Systems Engineer