Hello, I'm currently having some trouble with FreeRadius authentication. Posting my troubles at the Ubuntu forums didn't seem to help much, so I'm trying my hand here at the mailing lists. Here is the situation: We have recently aquired a Ruckus Zone director to manage our networks. We then wanted to have a Radius server to authenticate users thourgh their mac address. So, I installed Ubuntu, followed some basic tutorials and got all the way up to the point where I can join the radius controlled network. Problem is that while connected to this wireless network, I can't connect to internet and get booted from it in less than a minute with no message in radius debug for me to solve this problem. Here is the debug when connecting to the radius network: Ready to process requests. rad_recv: Access-Request packet from host 192.168.154.12 port 1065, id=9, length=168 User-Name = "Client mac address here" User-Password = "Client mac address here" Calling-Station-Id = "Client mac address here" NAS-IP-Address = 192.168.154.12 Called-Station-Id = "Ruckus mac address here:opetusx" Service-Type = Framed-User NAS-Port-Type = Wireless-802.11 NAS-Identifier = "Ruckus mac address here" Vendor-25053-Attr-3 = 0x6f706574757378 Message-Authenticator = 0xa7676bfa2ace5b4ba05356c35cac255a # Executing section authorize from file /etc/freeradius/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok [authorized_macs] expand: %{Calling-Station-ID} -> Client mac address here [authorized_macs] users: Matched entry Client mac address here at line 2 ++[authorized_macs] returns ok ++? if (!ok) ? Evaluating !(ok) -> FALSE ++? if (!ok) -> FALSE ++- entering else else {...} +++? if (!EAP-message) ? Evaluating !(EAP-message) -> TRUE +++? if (!EAP-message) -> TRUE +++- entering if (!EAP-message) {...} ++++[control] returns ok +++- if (!EAP-message) returns ok ++- else else returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop [suffix] No '@' in User-Name = "Client mac address here", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] No EAP-Message, not doing EAP ++[eap] returns noop ++[files] returns noop ++[expiration] returns noop ++[logintime] returns noop [pap] WARNING: Auth-Type already set. Not setting to PAP ++[pap] returns noop Found Auth-Type = Accept Auth-Type = Accept, accepting the user # Executing section post-auth from file /etc/freeradius/sites-enabled/default +- entering group post-auth {...} ++[exec] returns noop Sending Access-Accept of id 9 to 192.168.154.12 port 1065 Finished request 0. Going to the next request Waking up in 4.9 seconds. Cleaning up request 0 ID 9 with timestamp +7 Ready to process requests. I followed the plain mac auth guide to get this far, and the system sort of works, but not quite. So the configs must be out of whack somehow, but since radius doesn't give any debug info when I get booted out of the network I'm at loss here. Any help?
++[pap] returns noop Found Auth-Type = Accept Auth-Type = Accept, accepting the user
# Executing section post-auth from file /etc/freeradius/sites-enabled/default +- entering group post-auth {...} ++[exec] returns noop Sending Access-Accept of id 9 to 192.168.154.12 port 1065 Finished request 0. Going to the next request Waking up in 4.9 seconds. Cleaning up request 0 ID 9 with timestamp +7 Ready to process requests.
I followed the plain mac auth guide to get this far, and the system sort of works, but not quite. So the configs must be out of whack somehow, but since radius doesn't give any debug info when I get booted out of the network I'm at loss here. Any help?
If you're not seeing any information in the FreeRADIUS debug, then the Ruckus controller isn't sending anything. If you enable RADIUS accounting on the Ruckus you *may* get an Accounting-Request with the Acct-Terminate-Cause, which may give you a clue as to what's happening. First though I would enable debugging logs on the controller to see if it's complaining about the Access-Accept coming back, it may be missing some attributes that the Ruckus controller needs. I'd also verify the Access-Accept is actually reaching the controller (maybe dodgy routing). It may also be that the Ruckus requires a Message-Authenticator in the Access-Accept, in which case inserting: update reply { Message-Authenticator = 0x00 } Should trigger its generation. I'd also try: update reply { Service-Type = Framed-User } (some NAS require a service type). The delay suggests that the Ruckus may be discarding the responses from the RADIUS server, or never actually received the response. Do you see the request sent multiple times? -Arran
I know a little about Ruckus. Can you SSH to the ZD and input the following enable show aaa show wlan and send me the output direclty. Maybe there is something strange there. Also tell me which FW you are using and which OS the client is using (tell me which SP if Windows) Regards On 3 December 2012 12:30, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
++[pap] returns noop Found Auth-Type = Accept Auth-Type = Accept, accepting the user
# Executing section post-auth from file /etc/freeradius/sites-enabled/default +- entering group post-auth {...} ++[exec] returns noop Sending Access-Accept of id 9 to 192.168.154.12 port 1065 Finished request 0. Going to the next request Waking up in 4.9 seconds. Cleaning up request 0 ID 9 with timestamp +7 Ready to process requests.
I followed the plain mac auth guide to get this far, and the system sort of works, but not quite. So the configs must be out of whack somehow, but since radius doesn't give any debug info when I get booted out of the network I'm at loss here. Any help?
If you're not seeing any information in the FreeRADIUS debug, then the Ruckus controller isn't sending anything. If you enable RADIUS accounting on the Ruckus you *may* get an Accounting-Request with the Acct-Terminate-Cause, which may give you a clue as to what's happening.
First though I would enable debugging logs on the controller to see if it's complaining about the Access-Accept coming back, it may be missing some attributes that the Ruckus controller needs.
I'd also verify the Access-Accept is actually reaching the controller (maybe dodgy routing).
It may also be that the Ruckus requires a Message-Authenticator in the Access-Accept, in which case inserting:
update reply { Message-Authenticator = 0x00 }
Should trigger its generation.
I'd also try:
update reply { Service-Type = Framed-User }
(some NAS require a service type).
The delay suggests that the Ruckus may be discarding the responses from the RADIUS server, or never actually received the response. Do you see the request sent multiple times?
-Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Primož Marinšek
Well, I'm home right now, but tomorrow when I get back to work I'll see what I can do. Client is a Windows 7, but I can also test with XP and Win 8 clients if necessary. 2012/12/3 Primož Marinšek <pmtelos@gmail.com>
I know a little about Ruckus. Can you SSH to the ZD and input the following
enable show aaa show wlan
and send me the output direclty. Maybe there is something strange there.
Also tell me which FW you are using and which OS the client is using (tell me which SP if Windows)
Regards
On 3 December 2012 12:30, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
++[pap] returns noop Found Auth-Type = Accept Auth-Type = Accept, accepting the user
# Executing section post-auth from file
/etc/freeradius/sites-enabled/default
+- entering group post-auth {...} ++[exec] returns noop Sending Access-Accept of id 9 to 192.168.154.12 port 1065 Finished request 0. Going to the next request Waking up in 4.9 seconds. Cleaning up request 0 ID 9 with timestamp +7 Ready to process requests.
I followed the plain mac auth guide to get this far, and the system sort of works, but not quite. So the configs must be out of whack somehow, but since radius doesn't give any debug info when I get booted out of the network I'm at loss here. Any help?
If you're not seeing any information in the FreeRADIUS debug, then the Ruckus controller isn't sending anything. If you enable RADIUS accounting on the Ruckus you *may* get an Accounting-Request with the Acct-Terminate-Cause, which may give you a clue as to what's happening.
First though I would enable debugging logs on the controller to see if it's complaining about the Access-Accept coming back, it may be missing some attributes that the Ruckus controller needs.
I'd also verify the Access-Accept is actually reaching the controller (maybe dodgy routing).
It may also be that the Ruckus requires a Message-Authenticator in the Access-Accept, in which case inserting:
update reply { Message-Authenticator = 0x00 }
Should trigger its generation.
I'd also try:
update reply { Service-Type = Framed-User }
(some NAS require a service type).
The delay suggests that the Ruckus may be discarding the responses from the RADIUS server, or never actually received the response. Do you see the request sent multiple times?
-Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Primož Marinšek - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
User[client mac address] fails authentication too many times in a row when joining WLAN[opetus-x/opetusx] at AP[ap1<https://192.168.154.12/admin/mon_ap.jsp?n=c4:01:7c:1a:50:60>]. User[client mac address] is temporarily blocked from the system for [30 seconds]. Ok, after doing some searching I found more comprehensive logs on Ruckus which reveal the previous lines when trying to connect to the radius network. So, apparently it never actually does connect to it, but since the authentication happens OK on the FreeRadius side, I'm left to believe that it is in fact Ruckus who isn't happy with me trying to join the network. 2012/12/3 Taneli Virtanen <virtanentaneli@gmail.com>
Well, I'm home right now, but tomorrow when I get back to work I'll see what I can do. Client is a Windows 7, but I can also test with XP and Win 8 clients if necessary.
2012/12/3 Primož Marinšek <pmtelos@gmail.com>
I know a little about Ruckus. Can you SSH to the ZD and input the following
enable show aaa show wlan
and send me the output direclty. Maybe there is something strange there.
Also tell me which FW you are using and which OS the client is using (tell me which SP if Windows)
Regards
On 3 December 2012 12:30, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
++[pap] returns noop Found Auth-Type = Accept Auth-Type = Accept, accepting the user
# Executing section post-auth from file
/etc/freeradius/sites-enabled/default
+- entering group post-auth {...} ++[exec] returns noop Sending Access-Accept of id 9 to 192.168.154.12 port 1065 Finished request 0. Going to the next request Waking up in 4.9 seconds. Cleaning up request 0 ID 9 with timestamp +7 Ready to process requests.
I followed the plain mac auth guide to get this far, and the system sort of works, but not quite. So the configs must be out of whack somehow, but since radius doesn't give any debug info when I get booted out of the network I'm at loss here. Any help?
If you're not seeing any information in the FreeRADIUS debug, then the Ruckus controller isn't sending anything. If you enable RADIUS accounting on the Ruckus you *may* get an Accounting-Request with the Acct-Terminate-Cause, which may give you a clue as to what's happening.
First though I would enable debugging logs on the controller to see if it's complaining about the Access-Accept coming back, it may be missing some attributes that the Ruckus controller needs.
I'd also verify the Access-Accept is actually reaching the controller (maybe dodgy routing).
It may also be that the Ruckus requires a Message-Authenticator in the Access-Accept, in which case inserting:
update reply { Message-Authenticator = 0x00 }
Should trigger its generation.
I'd also try:
update reply { Service-Type = Framed-User }
(some NAS require a service type).
The delay suggests that the Ruckus may be discarding the responses from the RADIUS server, or never actually received the response. Do you see the request sent multiple times?
-Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Primož Marinšek - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 4 December 2012 08:32, Taneli Virtanen <virtanentaneli@gmail.com> wrote:
So, apparently it never actually does connect to it, but since the authentication happens OK on the FreeRadius side, I'm left to believe that it is in fact Ruckus who isn't happy with me trying to join the network.
I'm still a big noob with freeRADIUS but I will say that it works ok as I know that smart people are coding it. I've seen ZD work with freeRADIUS and other RADIUS's with no issues at all also, so please tell me which FW you are running on the ZD? -- Primož Marinšek
On 12/04/2012 07:32 AM, Taneli Virtanen wrote:
User[client mac address] fails authentication too many times in a row when joining WLAN[opetus-x/opetusx] at AP[ap1 <https://192.168.154.12/admin/mon_ap.jsp?n=c4:01:7c:1a:50:60>]. User[client mac address] is temporarily blocked from the system for [30 seconds].
Ok, after doing some searching I found more comprehensive logs on Ruckus which reveal the previous lines when trying to connect to the radius network.
So, apparently it never actually does connect to it, but since the authentication happens OK on the FreeRadius side, I'm left to believe that it is in fact Ruckus who isn't happy with me trying to join the network.
It might be EAP-identity packets hitting timeout/retry limits, due to wireless-level problems (interference, poor signal). This is very common, and lots of people tend to "associate" (pardon the pun) the problem with authentication, but in truth the identity request is really "just prior" to auth starting. It's only once the client sends an identity response that EAP gets started.
Hi,
Found Auth-Type = Accept Auth-Type = Accept, accepting the user
RADIUS all okay
I followed the plain mac auth guide to get this far, and the system sort of works, but not quite. So the configs must be out of whack somehow, but since radius doesn't give any debug info when I get booted out of the network I'm at loss here. Any help?
why would it (give you any info) - its done its job, authenticating your system as required. your problem is on your controller - what else o you have to send to the Ruckus along with the access-aceppt. do you also need to send other stuff? is the problem some nice L2/L3 network issue - such as the network you are dropping the client onto doesnt exist in the controller...or there is no routing for it or no DHCP available to the client? not a RADIUS problem alan
participants (5)
-
Alan Buxey -
Arran Cudbard-Bell -
Phil Mayers -
Primož Marinšek -
Taneli Virtanen