Freeradius 1.1.6 and Cisco 2000 Wirelss Controller
Hi, I've gotten a bit further but am still getting stuck. I have the Cisco Wireless Controller configured to hit Freeradius for MAC Address Authentication. Freeradius sees the request from the controller and sends back the configure attributes from the users file but the controller doesn't seem to see it correctly (the desired VLAN tag) and I end up in the default VLAN as configured on the controller. Below is my users, clients.conf, and radiusd verbose data output. Any thoughts? Ready to process requests. rad_recv: Access-Request packet from host 148.85.34.82:32768, id=35, length=174 User-Name = "00:0e:35:1c:e0:52" Called-Station-Id = "00-1a-6d-6b-f0-80:2000test" Calling-Station-Id = "00-0e-35-1c-e0-52" NAS-Port = 1 NAS-IP-Address = 148.85.34.82 NAS-Identifier = "WLC-34-82" Airespace-Wlan-Id = 1 User-Password = "testing" Service-Type = Call-Check Framed-MTU = 1300 NAS-Port-Type = Wireless-802.11 Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Private-Group-Id:0 = "159" Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 modcall[authorize]: module "chap" returns noop for request 0 modcall[authorize]: module "mschap" returns noop for request 0 rlm_realm: No '@' in User-Name = "00:0e:35:1c:e0:52", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 0 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 0 users: Matched entry 00:0e:35:1c:e0:52 at line 80 modcall[authorize]: module "files" returns ok for request 0 modcall: leaving group authorize (returns ok) for request 0 rad_check_password: Found Auth-Type Local auth: type Local auth: user supplied User-Password matches local User-Password Sending Access-Accept of id 35 to 148.85.34.82 port 32768 Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Type:0 = VLAN Tunnel-Private-Group-Id:0 = "157" Finished request 0 Going to the next request --- Walking the entire request list --- Waking up in 6 seconds... --- Walking the entire request list --- Cleaning up request 0 ID 35 with timestamp 4697de6a Nothing to do. Sleeping until we see a request. ____________________________________________________________ 00:0e:35:1c:e0:52 Auth-Type := Local, User-Password == "testing" Tunnel-Medium-Type = "IEEE-802", Tunnel-Type = "VLAN", Tunnel-Private-Group-Id = "157", ______________________________________________________________ client 148.85.34.82 { # # The shared secret use to "encrypt" and "sign" packets between # the NAS and FreeRADIUS. You MUST change this secret from the # default, otherwise it's not a secret any more! # # The secret can be any string, up to 31 characters in length. # secret = xxxxxxx # # The short name is used as an alias for the fully qualified # domain name, or the IP address. # shortname = controller # # the following three fields are optional, but may be used by # checkrad.pl for simultaneous use checks # # # The nastype tells 'checkrad.pl' which NAS-specific method to # use to query the NAS for simultaneous use. # # Permitted NAS types are: # # cisco # computone # livingston # max40xx # multitech # netserver # pathras # patton # portslave # tc # usrhiper # other # for all other types # nastype = other # localhost isn't usually a NAS... _____________________ Brian Ertel Network Administrator Amherst College 413-542-8320 bsertel@amherst.edu _____________________
Hi Alan, What should I be looking for in the eap.conf file? Thanks, Brian -----Original Message----- From: freeradius-users-bounces+bsertel=amherst.edu@lists.freeradius.org [mailto:freeradius-users-bounces+bsertel=amherst.edu@lists.freeradius.or g] On Behalf Of A.L.M.Buxey@lboro.ac.uk Sent: Friday, July 13, 2007 5:16 PM To: FreeRadius users mailing list Subject: Re: Freeradius 1.1.6 and Cisco 2000 Wirelss Controller ....and your eap.conf? alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Alan, I did not modify this file at all.... # Whatever you do, do NOT set 'Auth-Type := EAP'. The server # is smart enough to figure this out on its own. The most # common side effect of setting 'Auth-Type := EAP' is that the # users then cannot use ANY other authentication method. # # $Id: eap.conf,v 1.4.4.3 2006/04/28 18:25:03 aland Exp $ # eap { # Invoke the default supported EAP type when # EAP-Identity response is received. # # The incoming EAP messages DO NOT specify which EAP # type they will be using, so it MUST be set here. # # For now, only one default EAP type may be used at a time. # # If the EAP-Type attribute is set by another module, # then that EAP type takes precedence over the # default type configured here. # default_eap_type = md5 # A list is maintained to correlate EAP-Response # packets with EAP-Request packets. After a # configurable length of time, entries in the list # expire, and are deleted. # timer_expire = 60 # There are many EAP types, but the server has support # for only a limited subset. If the server receives # a request for an EAP type it does not support, then # it normally rejects the request. By setting this # configuration to "yes", you can tell the server to # instead keep processing the request. Another module # MUST then be configured to proxy the request to # another RADIUS server which supports that EAP type. # # If another module is NOT configured to handle the # request, then the request will still end up being # rejected. ignore_unknown_eap_types = no # Cisco AP1230B firmware 12.2(13)JA1 has a bug. When given # a User-Name attribute in an Access-Accept, it copies one # more byte than it should. # # We can work around it by configurably adding an extra # zero byte. cisco_accounting_username_bug = no # Supported EAP-types # # We do NOT recommend using EAP-MD5 authentication # for wireless connections. It is insecure, and does # not provide for dynamic WEP keys. # md5 { } # Cisco LEAP # # We do not recommend using LEAP in new deployments. See: # http://www.securiteam.com/tools/5TP012ACKE.html # # Cisco LEAP uses the MS-CHAP algorithm (but not # the MS-CHAP attributes) to perform it's authentication. # # As a result, LEAP *requires* access to the plain-text # User-Password, or the NT-Password attributes. # 'System' authentication is impossible with LEAP. # leap { } # Generic Token Card. # # Currently, this is only permitted inside of EAP-TTLS, # or EAP-PEAP. The module "challenges" the user with # text, and the response from the user is taken to be # the User-Password. # # Proxying the tunneled EAP-GTC session is a bad idea, # the users password will go over the wire in plain-text, # for anyone to see. # gtc { # The default challenge, which many clients # ignore.. #challenge = "Password: " # The plain-text response which comes back # is put into a User-Password attribute, # and passed to another module for # authentication. This allows the EAP-GTC # response to be checked against plain-text, # or crypt'd passwords. # # If you say "Local" instead of "PAP", then # the module will look for a User-Password # configured for the request, and do the # authentication itself. # auth_type = PAP } ## EAP-TLS # # To generate ctest certificates, run the script # # ../scripts/certs.sh # # The documents on http://www.freeradius.org/doc # are old, but may be helpful. # # See also: # # http://www.dslreports.com/forum/remark,9286052~mode=flat # #tls { # private_key_password = whatever # private_key_file = ${raddbdir}/certs/cert-srv.pem # If Private key & Certificate are located in # the same file, then private_key_file & # certificate_file must contain the same file # name. # certificate_file = ${raddbdir}/certs/cert-srv.pem # Trusted Root CA list # CA_file = ${raddbdir}/certs/demoCA/cacert.pem # dh_file = ${raddbdir}/certs/dh # random_file = ${raddbdir}/certs/random # # This can never exceed the size of a RADIUS # packet (4096 bytes), and is preferably half # that, to accomodate other attributes in # RADIUS packet. On most APs the MAX packet # length is configured between 1500 - 1600 # In these cases, fragment size should be # 1024 or less. # # fragment_size = 1024 # include_length is a flag which is # by default set to yes If set to # yes, Total Length of the message is # included in EVERY packet we send. # If set to no, Total Length of the # message is included ONLY in the # First packet of a fragment series. # # include_length = yes # Check the Certificate Revocation List # # 1) Copy CA certificates and CRLs to same directory. # 2) Execute 'c_rehash <CA certs&CRLs Directory>'. # 'c_rehash' is OpenSSL's command. # 3) Add 'CA_path=<CA certs&CRLs directory>' # to radiusd.conf's tls section. # 4) uncomment the line below. # 5) Restart radiusd # check_crl = yes # # If check_cert_issuer is set, the value will # be checked against the DN of the issuer in # the client certificate. If the values do not # match, the cerficate verification will fail, # rejecting the user. # # check_cert_issuer = "/C=GB/ST=Berkshire/L=Newbury/O=My Company Ltd" # # If check_cert_cn is set, the value will # be xlat'ed and checked against the CN # in the client certificate. If the values # do not match, the certificate verification # will fail rejecting the user. # # This check is done only if the previous # "check_cert_issuer" is not set, or if # the check succeeds. # # check_cert_cn = %{User-Name} # # Set this option to specify the allowed # TLS cipher suites. The format is listed # in "man 1 ciphers". # cipher_list = "DEFAULT" #} # The TTLS module implements the EAP-TTLS protocol, # which can be described as EAP inside of Diameter, # inside of TLS, inside of EAP, inside of RADIUS... # # Surprisingly, it works quite well. # # The TTLS module needs the TLS module to be installed # and configured, in order to use the TLS tunnel # inside of the EAP packet. You will still need to # configure the TLS module, even if you do not want # to deploy EAP-TLS in your network. Users will not # be able to request EAP-TLS, as it requires them to # have a client certificate. EAP-TTLS does not # require a client certificate. # #ttls { # The tunneled EAP session needs a default # EAP type which is separate from the one for # the non-tunneled EAP module. Inside of the # TTLS tunnel, we recommend using EAP-MD5. # If the request does not contain an EAP # conversation, then this configuration entry # is ignored. # default_eap_type = md5 # The tunneled authentication request does # not usually contain useful attributes # like 'Calling-Station-Id', etc. These # attributes are outside of the tunnel, # and normally unavailable to the tunneled # authentication request. # # By setting this configuration entry to # 'yes', any attribute which NOT in the # tunneled authentication request, but # which IS available outside of the tunnel, # is copied to the tunneled request. # # allowed values: {no, yes} # copy_request_to_tunnel = no # The reply attributes sent to the NAS are # usually based on the name of the user # 'outside' of the tunnel (usually # 'anonymous'). If you want to send the # reply attributes based on the user name # inside of the tunnel, then set this # configuration entry to 'yes', and the reply # to the NAS will be taken from the reply to # the tunneled request. # # allowed values: {no, yes} # use_tunneled_reply = no #} # # The tunneled EAP session needs a default EAP type # which is separate from the one for the non-tunneled # EAP module. Inside of the TLS/PEAP tunnel, we # recommend using EAP-MS-CHAPv2. # # The PEAP module needs the TLS module to be installed # and configured, in order to use the TLS tunnel # inside of the EAP packet. You will still need to # configure the TLS module, even if you do not want # to deploy EAP-TLS in your network. Users will not # be able to request EAP-TLS, as it requires them to # have a client certificate. EAP-PEAP does not # require a client certificate. # # peap { # The tunneled EAP session needs a default # EAP type which is separate from the one for # the non-tunneled EAP module. Inside of the # PEAP tunnel, we recommend using MS-CHAPv2, # as that is the default type supported by # Windows clients. # default_eap_type = mschapv2 # the PEAP module also has these configuration # items, which are the same as for TTLS. # copy_request_to_tunnel = no # use_tunneled_reply = no # When the tunneled session is proxied, the # home server may not understand EAP-MSCHAP-V2. # Set this entry to "no" to proxy the tunneled # EAP-MSCHAP-V2 as normal MSCHAPv2. # proxy_tunneled_request_as_eap = yes #} # # This takes no configuration. # # Note that it is the EAP MS-CHAPv2 sub-module, not # the main 'mschap' module. # # Note also that in order for this sub-module to work, # the main 'mschap' module MUST ALSO be configured. # # This module is the *Microsoft* implementation of MS-CHAPv2 # in EAP. There is another (incompatible) implementation # of MS-CHAPv2 in EAP by Cisco, which FreeRADIUS does not # currently support. # mschapv2 { } } -----Original Message----- From: freeradius-users-bounces+bsertel=amherst.edu@lists.freeradius.org on behalf of A.L.M.Buxey@lboro.ac.uk Sent: Mon 7/16/2007 9:46 AM To: FreeRadius users mailing list Subject: Re: Freeradius 1.1.6 and Cisco 2000 Wirelss Controller Hi,
What should I be looking for in the eap.conf file?
whether you are tunneling the reply in PEAP and TTLS. by not providing this list with your config files you arent helping us to help you. alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
He is not tunneling the request, just doing MAC auth. Problem is on the controller. debug aaa on it and see why is VLAN override not working. You are sure that override is on for that SSID? Ivan Kalik Kalik Informatika ISP Dana 16/7/2007, "Brian Ertel" <bsertel@amherst.edu> piše:
Alan,
I did not modify this file at all....
# Whatever you do, do NOT set 'Auth-Type := EAP'. The server # is smart enough to figure this out on its own. The most # common side effect of setting 'Auth-Type := EAP' is that the # users then cannot use ANY other authentication method. # # $Id: eap.conf,v 1.4.4.3 2006/04/28 18:25:03 aland Exp $ # eap { # Invoke the default supported EAP type when # EAP-Identity response is received. # # The incoming EAP messages DO NOT specify which EAP # type they will be using, so it MUST be set here. # # For now, only one default EAP type may be used at a time. # # If the EAP-Type attribute is set by another module, # then that EAP type takes precedence over the # default type configured here. # default_eap_type = md5
# A list is maintained to correlate EAP-Response # packets with EAP-Request packets. After a # configurable length of time, entries in the list # expire, and are deleted. # timer_expire = 60
# There are many EAP types, but the server has support # for only a limited subset. If the server receives # a request for an EAP type it does not support, then # it normally rejects the request. By setting this # configuration to "yes", you can tell the server to # instead keep processing the request. Another module # MUST then be configured to proxy the request to # another RADIUS server which supports that EAP type. # # If another module is NOT configured to handle the # request, then the request will still end up being # rejected. ignore_unknown_eap_types = no
# Cisco AP1230B firmware 12.2(13)JA1 has a bug. When given # a User-Name attribute in an Access-Accept, it copies one # more byte than it should. # # We can work around it by configurably adding an extra # zero byte. cisco_accounting_username_bug = no
# Supported EAP-types
# # We do NOT recommend using EAP-MD5 authentication # for wireless connections. It is insecure, and does # not provide for dynamic WEP keys. # md5 { }
# Cisco LEAP # # We do not recommend using LEAP in new deployments. See: # http://www.securiteam.com/tools/5TP012ACKE.html # # Cisco LEAP uses the MS-CHAP algorithm (but not # the MS-CHAP attributes) to perform it's authentication. # # As a result, LEAP *requires* access to the plain-text # User-Password, or the NT-Password attributes. # 'System' authentication is impossible with LEAP. # leap { }
# Generic Token Card. # # Currently, this is only permitted inside of EAP-TTLS, # or EAP-PEAP. The module "challenges" the user with # text, and the response from the user is taken to be # the User-Password. # # Proxying the tunneled EAP-GTC session is a bad idea, # the users password will go over the wire in plain-text, # for anyone to see. # gtc { # The default challenge, which many clients # ignore.. #challenge = "Password: "
# The plain-text response which comes back # is put into a User-Password attribute, # and passed to another module for # authentication. This allows the EAP-GTC # response to be checked against plain-text, # or crypt'd passwords. # # If you say "Local" instead of "PAP", then # the module will look for a User-Password # configured for the request, and do the # authentication itself. # auth_type = PAP }
## EAP-TLS # # To generate ctest certificates, run the script # # ../scripts/certs.sh # # The documents on http://www.freeradius.org/doc # are old, but may be helpful. # # See also: # # http://www.dslreports.com/forum/remark,9286052~mode=flat # #tls { # private_key_password = whatever # private_key_file = ${raddbdir}/certs/cert-srv.pem
# If Private key & Certificate are located in # the same file, then private_key_file & # certificate_file must contain the same file # name. # certificate_file = ${raddbdir}/certs/cert-srv.pem
# Trusted Root CA list # CA_file = ${raddbdir}/certs/demoCA/cacert.pem
# dh_file = ${raddbdir}/certs/dh # random_file = ${raddbdir}/certs/random
# # This can never exceed the size of a RADIUS # packet (4096 bytes), and is preferably half # that, to accomodate other attributes in # RADIUS packet. On most APs the MAX packet # length is configured between 1500 - 1600 # In these cases, fragment size should be # 1024 or less. # # fragment_size = 1024
# include_length is a flag which is # by default set to yes If set to # yes, Total Length of the message is # included in EVERY packet we send. # If set to no, Total Length of the # message is included ONLY in the # First packet of a fragment series. # # include_length = yes
# Check the Certificate Revocation List # # 1) Copy CA certificates and CRLs to same directory. # 2) Execute 'c_rehash <CA certs&CRLs Directory>'. # 'c_rehash' is OpenSSL's command. # 3) Add 'CA_path=<CA certs&CRLs directory>' # to radiusd.conf's tls section. # 4) uncomment the line below. # 5) Restart radiusd # check_crl = yes
# # If check_cert_issuer is set, the value will # be checked against the DN of the issuer in # the client certificate. If the values do not # match, the cerficate verification will fail, # rejecting the user. # # check_cert_issuer = "/C=GB/ST=Berkshire/L=Newbury/O=My Company Ltd"
# # If check_cert_cn is set, the value will # be xlat'ed and checked against the CN # in the client certificate. If the values # do not match, the certificate verification # will fail rejecting the user. # # This check is done only if the previous # "check_cert_issuer" is not set, or if # the check succeeds. # # check_cert_cn = %{User-Name} # # Set this option to specify the allowed # TLS cipher suites. The format is listed # in "man 1 ciphers". # cipher_list = "DEFAULT" #}
# The TTLS module implements the EAP-TTLS protocol, # which can be described as EAP inside of Diameter, # inside of TLS, inside of EAP, inside of RADIUS... # # Surprisingly, it works quite well. # # The TTLS module needs the TLS module to be installed # and configured, in order to use the TLS tunnel # inside of the EAP packet. You will still need to # configure the TLS module, even if you do not want # to deploy EAP-TLS in your network. Users will not # be able to request EAP-TLS, as it requires them to # have a client certificate. EAP-TTLS does not # require a client certificate. # #ttls { # The tunneled EAP session needs a default # EAP type which is separate from the one for # the non-tunneled EAP module. Inside of the # TTLS tunnel, we recommend using EAP-MD5. # If the request does not contain an EAP # conversation, then this configuration entry # is ignored. # default_eap_type = md5
# The tunneled authentication request does # not usually contain useful attributes # like 'Calling-Station-Id', etc. These # attributes are outside of the tunnel, # and normally unavailable to the tunneled # authentication request. # # By setting this configuration entry to # 'yes', any attribute which NOT in the # tunneled authentication request, but # which IS available outside of the tunnel, # is copied to the tunneled request. # # allowed values: {no, yes} # copy_request_to_tunnel = no
# The reply attributes sent to the NAS are # usually based on the name of the user # 'outside' of the tunnel (usually # 'anonymous'). If you want to send the # reply attributes based on the user name # inside of the tunnel, then set this # configuration entry to 'yes', and the reply # to the NAS will be taken from the reply to # the tunneled request. # # allowed values: {no, yes} # use_tunneled_reply = no #}
# # The tunneled EAP session needs a default EAP type # which is separate from the one for the non-tunneled # EAP module. Inside of the TLS/PEAP tunnel, we # recommend using EAP-MS-CHAPv2. # # The PEAP module needs the TLS module to be installed # and configured, in order to use the TLS tunnel # inside of the EAP packet. You will still need to # configure the TLS module, even if you do not want # to deploy EAP-TLS in your network. Users will not # be able to request EAP-TLS, as it requires them to # have a client certificate. EAP-PEAP does not # require a client certificate. # # peap { # The tunneled EAP session needs a default # EAP type which is separate from the one for # the non-tunneled EAP module. Inside of the # PEAP tunnel, we recommend using MS-CHAPv2, # as that is the default type supported by # Windows clients. # default_eap_type = mschapv2
# the PEAP module also has these configuration # items, which are the same as for TTLS. # copy_request_to_tunnel = no # use_tunneled_reply = no
# When the tunneled session is proxied, the # home server may not understand EAP-MSCHAP-V2. # Set this entry to "no" to proxy the tunneled # EAP-MSCHAP-V2 as normal MSCHAPv2. # proxy_tunneled_request_as_eap = yes #}
# # This takes no configuration. # # Note that it is the EAP MS-CHAPv2 sub-module, not # the main 'mschap' module. # # Note also that in order for this sub-module to work, # the main 'mschap' module MUST ALSO be configured. # # This module is the *Microsoft* implementation of MS-CHAPv2 # in EAP. There is another (incompatible) implementation # of MS-CHAPv2 in EAP by Cisco, which FreeRADIUS does not # currently support. # mschapv2 { } }
-----Original Message----- From: freeradius-users-bounces+bsertel=amherst.edu@lists.freeradius.org on behalf of A.L.M.Buxey@lboro.ac.uk Sent: Mon 7/16/2007 9:46 AM To: FreeRadius users mailing list Subject: Re: Freeradius 1.1.6 and Cisco 2000 Wirelss Controller
Hi,
What should I be looking for in the eap.conf file?
whether you are tunneling the reply in PEAP and TTLS. by not providing this list with your config files you arent helping us to help you.
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Does anyone have actual examples of radclient (or other command-line tools) being used to test Freeradius using Windows Active Directory authentication via samba/ntlm_auth? I'd like to be able to test Radius authentication for various different categories of user on our Active Directory. Presumably this involves PEAP/MSCHAPv2 I can't work out how to do it without using a Windows client and a wireless infrastructure we don't have yet. (or even if it is doable) I can use radclient to test PAP and "straight" CHAP against locally defined users with cleartext passwords. Time to go one step further.
Hi,
Presumably this involves PEAP/MSCHAPv2 I can't work out how to do it without using a Windows client and a wireless infrastructure we don't have yet. (or even if it is doable)
you dont need wireless to do such testing - there are plenty of ethernet switches out there that do 802.1x and can throw the EAP authentication to your RADIUS box... ...with this in mind, you could use wpa_supplicant on linux - yes it does wired 802.1x nicely... eg have this in the config eap=PEAP identity="domain\username" password="secret_password" ca_cert="/etc/cert/ca.pem" phase1="peaplabel=0" phase2="auth=MSCHAPV2" or..since you're playing with wpa_supplicant..use its handy tool eapol_test - very useful. of course, with wired 802.1x you can also play with the windows client and get used to its quirks and foibles. alan
http://www.nabble.com/MSCHAP-test-client--tf4069370.html You don't need to do PEAP to test ntlm_auth, just MSCHAP. Ivan Kalik Kalik Informatika ISP Dana 18/7/2007, "ken" <k.brown@bbk.ac.uk> piše:
Does anyone have actual examples of radclient (or other command-line tools) being used to test Freeradius using Windows Active Directory authentication via samba/ntlm_auth?
I'd like to be able to test Radius authentication for various different categories of user on our Active Directory.
Presumably this involves PEAP/MSCHAPv2 I can't work out how to do it without using a Windows client and a wireless infrastructure we don't have yet. (or even if it is doable)
I can use radclient to test PAP and "straight" CHAP against locally defined users with cleartext passwords. Time to go one step further.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Radius is doing it's bit. Your problem is with the Controller configuration. Have you configured a VLAN with ID of 157 on the Controller? Have you enabled Radius override of default settings on WLAN? Ivan Kalik Kalik Informatika ISP Dana 13/7/2007, "Brian Ertel" <bsertel@amherst.edu> piše:
Hi,
I've gotten a bit further but am still getting stuck. I have the Cisco Wireless Controller configured to hit Freeradius for MAC Address Authentication. Freeradius sees the request from the controller and sends back the configure attributes from the users file but the controller doesn't seem to see it correctly (the desired VLAN tag) and I end up in the default VLAN as configured on the controller. Below is my users, clients.conf, and radiusd verbose data output. Any thoughts?
Ready to process requests. rad_recv: Access-Request packet from host 148.85.34.82:32768, id=35, length=174 User-Name = "00:0e:35:1c:e0:52" Called-Station-Id = "00-1a-6d-6b-f0-80:2000test" Calling-Station-Id = "00-0e-35-1c-e0-52" NAS-Port = 1 NAS-IP-Address = 148.85.34.82 NAS-Identifier = "WLC-34-82" Airespace-Wlan-Id = 1 User-Password = "testing" Service-Type = Call-Check Framed-MTU = 1300 NAS-Port-Type = Wireless-802.11 Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Private-Group-Id:0 = "159" Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 modcall[authorize]: module "chap" returns noop for request 0 modcall[authorize]: module "mschap" returns noop for request 0 rlm_realm: No '@' in User-Name = "00:0e:35:1c:e0:52", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 0 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 0 users: Matched entry 00:0e:35:1c:e0:52 at line 80 modcall[authorize]: module "files" returns ok for request 0 modcall: leaving group authorize (returns ok) for request 0 rad_check_password: Found Auth-Type Local auth: type Local auth: user supplied User-Password matches local User-Password Sending Access-Accept of id 35 to 148.85.34.82 port 32768 Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Type:0 = VLAN Tunnel-Private-Group-Id:0 = "157" Finished request 0 Going to the next request --- Walking the entire request list --- Waking up in 6 seconds... --- Walking the entire request list --- Cleaning up request 0 ID 35 with timestamp 4697de6a Nothing to do. Sleeping until we see a request.
____________________________________________________________
00:0e:35:1c:e0:52 Auth-Type := Local, User-Password == "testing"
Tunnel-Medium-Type = "IEEE-802", Tunnel-Type = "VLAN", Tunnel-Private-Group-Id = "157",
______________________________________________________________
client 148.85.34.82 { # # The shared secret use to "encrypt" and "sign" packets between # the NAS and FreeRADIUS. You MUST change this secret from the # default, otherwise it's not a secret any more! # # The secret can be any string, up to 31 characters in length. # secret = xxxxxxx
# # The short name is used as an alias for the fully qualified # domain name, or the IP address. # shortname = controller
# # the following three fields are optional, but may be used by # checkrad.pl for simultaneous use checks #
# # The nastype tells 'checkrad.pl' which NAS-specific method to # use to query the NAS for simultaneous use. # # Permitted NAS types are: # # cisco # computone # livingston # max40xx # multitech # netserver # pathras # patton # portslave # tc # usrhiper # other # for all other types
# nastype = other # localhost isn't usually a NAS...
_____________________
Brian Ertel Network Administrator Amherst College 413-542-8320 bsertel@amherst.edu _____________________
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Ivan, Yes, the controller does have VLAN 157 configured, that is actually the original client vlan configured before I started testing with vlan tags from freeradius. Thanks, Brian -----Original Message----- From: freeradius-users-bounces+bsertel=amherst.edu@lists.freeradius.org [mailto:freeradius-users-bounces+bsertel=amherst.edu@lists.freeradius.org] On Behalf Of tnt@kalik.co.yu Sent: Saturday, July 14, 2007 11:26 AM To: FreeRadius users mailing list Subject: Re: Freeradius 1.1.6 and Cisco 2000 Wirelss Controller Radius is doing it's bit. Your problem is with the Controller configuration. Have you configured a VLAN with ID of 157 on the Controller? Have you enabled Radius override of default settings on WLAN? Ivan Kalik Kalik Informatika ISP Dana 13/7/2007, "Brian Ertel" <bsertel@amherst.edu> piše:
Hi,
I've gotten a bit further but am still getting stuck. I have the Cisco Wireless Controller configured to hit Freeradius for MAC Address Authentication. Freeradius sees the request from the controller and sends back the configure attributes from the users file but the controller doesn't seem to see it correctly (the desired VLAN tag) and I end up in the default VLAN as configured on the controller. Below is my users, clients.conf, and radiusd verbose data output. Any thoughts?
Ready to process requests. rad_recv: Access-Request packet from host 148.85.34.82:32768, id=35, length=174 User-Name = "00:0e:35:1c:e0:52" Called-Station-Id = "00-1a-6d-6b-f0-80:2000test" Calling-Station-Id = "00-0e-35-1c-e0-52" NAS-Port = 1 NAS-IP-Address = 148.85.34.82 NAS-Identifier = "WLC-34-82" Airespace-Wlan-Id = 1 User-Password = "testing" Service-Type = Call-Check Framed-MTU = 1300 NAS-Port-Type = Wireless-802.11 Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Private-Group-Id:0 = "159" Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 modcall[authorize]: module "chap" returns noop for request 0 modcall[authorize]: module "mschap" returns noop for request 0 rlm_realm: No '@' in User-Name = "00:0e:35:1c:e0:52", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 0 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 0 users: Matched entry 00:0e:35:1c:e0:52 at line 80 modcall[authorize]: module "files" returns ok for request 0 modcall: leaving group authorize (returns ok) for request 0 rad_check_password: Found Auth-Type Local auth: type Local auth: user supplied User-Password matches local User-Password Sending Access-Accept of id 35 to 148.85.34.82 port 32768 Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Type:0 = VLAN Tunnel-Private-Group-Id:0 = "157" Finished request 0 Going to the next request --- Walking the entire request list --- Waking up in 6 seconds... --- Walking the entire request list --- Cleaning up request 0 ID 35 with timestamp 4697de6a Nothing to do. Sleeping until we see a request.
____________________________________________________________
00:0e:35:1c:e0:52 Auth-Type := Local, User-Password == "testing"
Tunnel-Medium-Type = "IEEE-802", Tunnel-Type = "VLAN", Tunnel-Private-Group-Id = "157",
______________________________________________________________
client 148.85.34.82 { # # The shared secret use to "encrypt" and "sign" packets between # the NAS and FreeRADIUS. You MUST change this secret from the # default, otherwise it's not a secret any more! # # The secret can be any string, up to 31 characters in length. # secret = xxxxxxx
# # The short name is used as an alias for the fully qualified # domain name, or the IP address. # shortname = controller
# # the following three fields are optional, but may be used by # checkrad.pl for simultaneous use checks #
# # The nastype tells 'checkrad.pl' which NAS-specific method to # use to query the NAS for simultaneous use. # # Permitted NAS types are: # # cisco # computone # livingston # max40xx # multitech # netserver # pathras # patton # portslave # tc # usrhiper # other # for all other types
# nastype = other # localhost isn't usually a NAS...
_____________________
Brian Ertel Network Administrator Amherst College 413-542-8320 bsertel@amherst.edu _____________________
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (4)
-
A.L.M.Buxey＠lboro.ac.uk -
Brian Ertel -
ken -
tnt＠kalik.co.yu