Re: Problem with Cisco WLC probes in FR 2.2.1
On 7 Oct 2013, at 02:30, Bruce Nunn ironr...@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.gaze...@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)'
signature.asc
Description: Message signed with OpenPGP using GPGMail
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problem with Cisco WLC probes in FR 2.2.1
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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problem with Cisco WLC probes in FR 2.2.1
On 10/07/2013 08:40 AM, a.l.m.bu...@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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problem with Cisco WLC probes in FR 2.2.1
On 07/10/13 08:40, a.l.m.bu...@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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problem with Cisco WLC probes in FR 2.2.1
On 7 Oct 2013, at 09:59, Jonathan Gazeley jonathan.gaze...@bristol.ac.uk
wrote:
On 07/10/13 08:40, a.l.m.bu...@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
signature.asc
Description: Message signed with OpenPGP using GPGMail
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problem with Cisco WLC probes in FR 2.2.1
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. yesbut 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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problem with Cisco WLC probes in FR 2.2.1
On 7 Oct 2013, at 10:36, a.l.m.bu...@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. yesbut 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.cudba...@freeradius.org FreeRADIUS Development Team - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problem with Cisco WLC probes in FR 2.2.1
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 insteadbut 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 proxiesas 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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problem with Cisco WLC probes in FR 2.2.1
On 7 Oct 2013, at 11:31, a.l.m.bu...@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 insteadbut 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.cudba...@freeradius.org FreeRADIUS Development Team - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
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.gaze...@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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Problem with Cisco WLC probes in FR 2.2.1
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
Re: Problem with Cisco WLC probes in FR 2.2.1
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'll be releasing 2.2.2 very soon to fix various issues with unlang. In the mean time could you try the current v2.x.x HEAD to see if it resolves your issues? -Arran Arran Cudbard-Bell a.cudba...@freeradius.org FreeRADIUS Development Team - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
