Re: Problem with Cisco WLC probes in FR 2.2.1
Thanks for the heads-up. I will look for this this coming weekend when I get 2.2.2 in production. Jonathan Gazeley <Jonathan.Gazeley@bristol.ac.uk> wrote:
We've recently upgraded our radius servers from 2.1.12 (CentOS 6 packaged default) to 2.2.1 (latest stable from FR, built by hand).
A config that used to work under 2.1.12 no longer appears to work the same way under 2.2.1. Our Cisco WLCs send periodic probes in the form of a test authentication. There is a snippet of config that intercepts these authentication requests:
# /etc/raddb/conf.d/wism-checks.conf if (Service-Type == "NAS-Prompt-User") { if (NAS-IP-Address =~ /^172\.17\.107\./) { if (User-Name =~ /^wisms\-testing/) { update control { Auth-Type := Accept } updated } else { reject } } updated = return }
This config is included in every virtual server's outer config:
# /etc/raddb/sites-enabled/eduroamlocal authorize { $INCLUDE conf.d/wism-checks.conf }
Looking at the output from radiusd -XC the wism-checks.conf file is being included in multiple places, yet when the server is running there is no record of these test probe packets being processed. This means the WLCs think the radius server is dead, and stop using it. I've had to roll back to 2.1.12 to restore stable wireless service for our users.
I can only assume this code block is being skipped over for some reason. At present I'm unable to drop production radius servers into debug mode since they can't handle the load while debugging, and while I do have some development radius servers, our WLCs won't sent it these probe packets unless it is an active production radius server.
Does anyone have any tips for debugging this in a minimally disruptive way? At the moment we don't have any development WLCs but we might have to get some so we can have a separate environment for testing. In the meantime I'm trying to get this code block to work so we can use the newer version of FR.
Thanks, and happy Friday Jonathan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 7 Oct 2013, at 02:30, Bruce Nunn <ironrake@yahoo.com> wrote:
Thanks for the heads-up. I will look for this this coming weekend when I get 2.2.2 in production.
Jonathan Gazeley <Jonathan.Gazeley@bristol.ac.uk> wrote:
We've recently upgraded our radius servers from 2.1.12 (CentOS 6 packaged default) to 2.2.1 (latest stable from FR, built by hand).
A config that used to work under 2.1.12 no longer appears to work the same way under 2.2.1. Our Cisco WLCs send periodic probes in the form of a test authentication. There is a snippet of config that intercepts these authentication requests:
# /etc/raddb/conf.d/wism-checks.conf if (Service-Type == "NAS-Prompt-User") { if (NAS-IP-Address =~ /^172\.17\.107\./) { if (User-Name =~ /^wisms\-testing/) { update control { Auth-Type := Accept } updated } else { reject } } updated = return }
This config is included in every virtual server's outer config:
# /etc/raddb/sites-enabled/eduroamlocal authorize { $INCLUDE conf.d/wism-checks.conf }
Looking at the output from radiusd -XC the wism-checks.conf file is being included in multiple places, yet when the server is running there is no record of these test probe packets being processed. This means the WLCs think the radius server is dead, and stop using it. I've had to roll back to 2.1.12 to restore stable wireless service for our users.
I can only assume this code block is being skipped over for some reason. At present I'm unable to drop production radius servers into debug mode since they can't handle the load while debugging, and while I do have some development radius servers, our WLCs won't sent it these probe packets unless it is an active production radius server.
Does anyone have any tips for debugging this in a minimally disruptive way? At the moment we don't have any development WLCs but we might have to get some so we can have a separate environment for testing. In the meantime I'm trying to get this code block to work so we can use the newer version of FR.
We don't have any extra code for the wism checks on our FreeRADIUS. The wism-check user is treated just like any other user, and consequently receives an Access-Reject (because it isn't a real user). Why send an access accept? The wism doesn't care what it gets back (Accept or Reject), it simply wants an answer from the radius so it knows it is alive. Have you tried running with your wism-checks config commented out? To debug I would first check the configuration on the wism. Make sure it is configured for Active fallback checks. Then I would use radmin, something like: set debug file wism-fallback-test set condition '(User-Name == wism-check)'
Hi,
if (Service-Type == "NAS-Prompt-User") { if (NAS-IP-Address =~ /^172\.17\.107\./) { if (User-Name =~ /^wisms\-testing/) { update control { Auth-Type := Accept }
ouch do you realise how dangerous that is? there should be no need to send an access accept packet back to these probes - a reject should suffice - and that would stop an end user subverting your system by simply using that UserName (if they are using wpa_supplicant they could add that NAS-Prompt-User attribute) alan
On 10/07/2013 08:40 AM, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
if (Service-Type == "NAS-Prompt-User") { if (NAS-IP-Address =~ /^172\.17\.107\./) { if (User-Name =~ /^wisms\-testing/) { update control { Auth-Type := Accept }
ouch do you realise how dangerous that is? there should be no need to send an access accept packet back to these probes - a reject should suffice - and that would stop an end user subverting your system by simply using that UserName (if they are using wpa_supplicant they could add that NAS-Prompt-User attribute)
Er... wpa_supplicant speaks EAP, and Service-Type is a RADIUS attribute.
On 07/10/13 08:40, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
if (Service-Type == "NAS-Prompt-User") { if (NAS-IP-Address =~ /^172\.17\.107\./) { if (User-Name =~ /^wisms\-testing/) { update control { Auth-Type := Accept } ouch do you realise how dangerous that is? there should be no need to send an access accept packet back to these probes - a reject should suffice - and that would stop an end user subverting your system by simply using that UserName (if they are using wpa_supplicant they could add that NAS-Prompt-User attribute)
alan -
We're finding these nuggets of code as we dig deeper into James's legacy config. If the Access-Accept response is not required, then presumably I can ditch that entire code block and let the wisms-testing auth attempt go through the system as any other user. Thanks, Jonathan
On 7 Oct 2013, at 09:59, Jonathan Gazeley <Jonathan.Gazeley@bristol.ac.uk> wrote:
On 07/10/13 08:40, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
if (Service-Type == "NAS-Prompt-User") { if (NAS-IP-Address =~ /^172\.17\.107\./) { if (User-Name =~ /^wisms\-testing/) { update control { Auth-Type := Accept } ouch do you realise how dangerous that is? there should be no need to send an access accept packet back to these probes - a reject should suffice - and that would stop an end user subverting your system by simply using that UserName (if they are using wpa_supplicant they could add that NAS-Prompt-User attribute)
alan -
We're finding these nuggets of code as we dig deeper into James's legacy config. If the Access-Accept response is not required, then presumably I can ditch that entire code block and let the wisms-testing auth attempt go through the system as any other user.
Yes, or immediately reject that user in the authorise section. Rejecting immediately just makes things more efficient, particularly if the wism is doing a check because it has marked the server as dead. Test it, see what happens. Regards Scott
Hi,
We're finding these nuggets of code as we dig deeper into James's legacy config. If the Access-Accept response is not required, then presumably I can ditch that entire code block and let the wisms-testing auth attempt go through the system as any other user.
yes....but you'd be better off just sending an immediate Access-Reject or these probes go through your whole config and hit your backend authentication servers for no reason. alan
On 7 Oct 2013, at 10:36, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
We're finding these nuggets of code as we dig deeper into James's legacy config. If the Access-Accept response is not required, then presumably I can ditch that entire code block and let the wisms-testing auth attempt go through the system as any other user.
yes....but you'd be better off just sending an immediate Access-Reject or these probes go through your whole config and hit your backend authentication servers for no reason.
Well you want the probes to go through and hit your backed authentication servers, and your databases, and any external resource. In the event of a failure of any of those modules you want to not respond to the WiSM. In 3.0.0 a really easy way to check for that sort of thing is using the presence of Module-Failure-Message, though you should be careful to clear it if you have redundant sections, or alternative behaviour on module failure. Previously Module-Failure-Message had to be set explicitly by the module, so wasn't implemented by all modules. In 3.0.0 when standardising the logging macros and added a call to set it on all request errors (RERROR, REDEBUG, REDEBUG2, REDEBUG3, REDEBUG4), which most, if not all modules use to log errors. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
Hi,
Well you want the probes to go through and hit your backed authentication servers, and your databases, and any external resource.
..and get a valid user with access accept? bad. you are better off just semding a reject - just like RADIUS status server probes. it would be nice if the WISM would do proper RADIUS status-server probe instead....but since cisco want you to buy ACS/ISE and that doesnt do nice things - then I guess we can live in hope - after all, if you were REALLY going to validate what the WISM and RADIUS server can do, you'd want your status check to go through your remote RADIUS server proxies....as the user might be a visitor or from some 3rd party org that you peer with - then we get into the whole business of the status probes being more intelligent with multiple realms etc etc... this is WAY off topic now ;-) alan
On 7 Oct 2013, at 11:31, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
Well you want the probes to go through and hit your backed authentication servers, and your databases, and any external resource.
..and get a valid user with access accept? bad. you are better off just semding a reject - just like RADIUS status server probes. it would be nice if the WISM would do proper RADIUS status-server probe instead....but since cisco want you to buy ACS/ISE and that doesnt do nice things - then I guess we can live in hope
No. You want a policy in post-auth which checks what happened when the test user's authentication was processed. Everything ok: Access-Reject Somethings wrong: Don't respond And you want to make sure that you have ACLs in place to only allow access to the RADIUS test user object from the RADIUS test server (obviously :) ). In regards to upstream proxy servers, i'll echo Alan D's thoughts on this, and say that it's really the responsibility of a AAA routing protocol. Though yes, for eduroam checking next hop connectivity is probably useful. Maybe an xlat method which returns the state of a realm? -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
participants (6)
-
A.L.M.Buxey＠lboro.ac.uk -
Arran Cudbard-Bell -
Bruce Nunn -
Jonathan Gazeley -
Phil Mayers -
Scott Armitage