Freeradius with PEAP (EAP-MSCHAP v2) Problems

[Khurram Jahangir]

Hello Everyone,

I am a new user on this mailing list and I am facing
some problems while trying to use PEAP and freeradius.

The freeradius version that I am using is 1.0.1. The
client is a windows XP machine with SP 2. The
authenticator is an HP 2524 switch.

The error that I get is this one

----------------

Processing the authenticate section of radiusd.conf
modcall: entering group Auth-Type for request 8
rlm_mschap: No MS-CHAP-Challenge in the request
modcall[authenticate]: module "mschap" returns
reject for request 8
modcall: group Auth-Type returns reject for request 8
auth: Failed to validate the user.

------------------


users file has the following user

"bob" Auth-Type := MS-CHAP, User-Password == "bob1"
Reply-Message = "Hello, %u"


I tried it without mentioning any Auth-Type and then
the server takes it as CHAP by default and it works.

--------------------

I have following configuration in eap.conf

eap {

default_eap_type = tls

timer_expire = 60

ignore_unknown_eap_types = no

cisco_accounting_username_bug = no

md5 {
}

leap {
}

gtc {
auth_type = PAP
}

tls {
private_key_password = whatever
private_key_file = /etc/1x/khurram.pem

certificate_file = /etc/1x/khurram.pem



CA_file = /etc/1x/root.pem



dh_file = /etc/1x/DH
random_file = /etc/1x/random

peap {
default_eap_type = mschapv2
copy_request_to_tunnel = yes
use_tunneled_reply = no
proxy_tunneled_request_as_eap = yes
}

mschapv2 {
}

}

}


-----------------------------

In eap.conf, under eap, if i change "default_eap_type"
to peap, the I get the following error while running
Radiusd and it crashes

rlm_eap: Loaded and initialized type tls
rlm_eap: No such sub-type for default EAP type peap
radiusd.conf[9]: eap: Module instantiation failed.

-----------------------------



In HP switch, I gave this command to make it work,

aaa authentication port-access chap-radius

--------------------------------

In the XP client, I have chosen Portected EAP (PEAP)
as the EAP type and I also have enabled the root
certificate authority. I have chosen Secured password
(EAP-MSCHAP v2) as the authentication method.



My setup worked fine for EAP-TLS and the certificates
and for MD5 Challange (CHAP).

Below is the debug output of the freeradius with
"default_eap_type = tls"

*********************************
[***@localhost root]# radiusd -X
Starting - reading configuration files ...
reread_config: reading radiusd.conf
Config: including file:
/usr/local/etc/raddb/proxy.conf
Config: including file:
/usr/local/etc/raddb/clients.conf
Config: including file:
/usr/local/etc/raddb/snmp.conf
Config: including file:
/usr/local/etc/raddb/eap.conf
Config: including file:
/usr/local/etc/raddb/sql.conf
main: prefix = "/usr/local"
main: localstatedir = "/usr/local/var"
main: logdir = "/usr/local/var/log/radius"
main: libdir = "/usr/local/lib"
main: radacctdir =
"/usr/local/var/log/radius/radacct"
main: hostname_lookups = no
main: max_request_time = 30
main: cleanup_delay = 5
main: max_requests = 1024
main: delete_blocked_requests = 0
main: port = 0
main: allow_core_dumps = no
main: log_stripped_names = no
main: log_file =
"/usr/local/var/log/radius/radius.log"
main: log_auth = no
main: log_auth_badpass = no
main: log_auth_goodpass = no
main: pidfile =
"/usr/local/var/run/radiusd/radiusd.pid"
main: user = "(null)"
main: group = "(null)"
main: usercollide = no
main: lower_user = "no"
main: lower_pass = "no"
main: nospace_user = "no"
main: nospace_pass = "no"
main: checkrad = "/usr/local/sbin/checkrad"
main: proxy_requests = yes
proxy: retry_delay = 5
proxy: retry_count = 3
proxy: synchronous = no
proxy: default_fallback = yes
proxy: dead_time = 120
proxy: post_proxy_authorize = yes
proxy: wake_all_if_all_dead = no
security: max_attributes = 200
security: reject_delay = 1
security: status_server = no
main: debug_level = 0
read_config_files: reading dictionary
read_config_files: reading naslist
Using deprecated naslist file. Support for this will
go away soon.
read_config_files: reading clients
read_config_files: reading realms
radiusd: entering modules setup
Module: Library search path is /usr/local/lib
Module: Loaded exec
exec: wait = yes
exec: program = "(null)"
exec: input_pairs = "request"
exec: output_pairs = "(null)"
exec: packet_type = "(null)"
rlm_exec: Wait=yes but no output defined. Did you mean
output=none?
Module: Instantiated exec (exec)
Module: Loaded expr
Module: Instantiated expr (expr)
Module: Loaded PAP
pap: encryption_scheme = "crypt"
Module: Instantiated pap (pap)
Module: Loaded CHAP
Module: Instantiated chap (chap)
Module: Loaded MS-CHAP
mschap: use_mppe = yes
mschap: require_encryption = yes
mschap: require_strong = yes
mschap: with_ntdomain_hack = yes
mschap: passwd = "(null)"
mschap: authtype = "MS-CHAP"
mschap: ntlm_auth = "(null)"
Module: Instantiated mschap (mschap)
Module: Loaded System
unix: cache = no
unix: passwd = "(null)"
unix: shadow = "(null)"
unix: group = "(null)"
unix: radwtmp = "/usr/local/var/log/radius/radwtmp"
unix: usegroup = no
unix: cache_reload = 600
Module: Instantiated unix (unix)
Module: Loaded eap
eap: default_eap_type = "tls"
eap: timer_expire = 60
eap: ignore_unknown_eap_types = no
eap: cisco_accounting_username_bug = no
rlm_eap: Loaded and initialized type md5
rlm_eap: Loaded and initialized type leap
gtc: challenge = "Password: "
gtc: auth_type = "PAP"
rlm_eap: Loaded and initialized type gtc
tls: rsa_key_exchange = no
tls: dh_key_exchange = yes
tls: rsa_key_length = 512
tls: dh_key_length = 512
tls: verify_depth = 0
tls: CA_path = "(null)"
tls: pem_file_type = yes
tls: private_key_file = "/etc/1x/khurram.pem"

tls: certificate_file = "/etc/1x/khurram.pem"
tls: CA_file = "/etc/1x/root.pem"
tls: private_key_password = "whatever"
tls: dh_file = "/etc/1x/DH"
tls: random_file = "/etc/1x/random"
tls: fragment_size = 1024
tls: include_length = yes
tls: check_crl = no
tls: check_cert_cn = "(null)"
rlm_eap: Loaded and initialized type tls
Module: Instantiated eap (eap)
Module: Loaded preprocess
preprocess: huntgroups =
"/usr/local/etc/raddb/huntgroups"
preprocess: hints = "/usr/local/etc/raddb/hints"
preprocess: with_ascend_hack = no
preprocess: ascend_channels_per_line = 23
preprocess: with_ntdomain_hack = no
preprocess: with_specialix_jetstream_hack = no
preprocess: with_cisco_vsa_hack = no
Module: Instantiated preprocess (preprocess)
Module: Loaded realm
realm: format = "suffix"
realm: delimiter = "@"
realm: ignore_default = no
realm: ignore_null = no
Module: Instantiated realm (suffix)
Module: Loaded files
files: usersfile = "/usr/local/etc/raddb/users"
files: acctusersfile =
"/usr/local/etc/raddb/acct_users"
files: preproxy_usersfile =
"/usr/local/etc/raddb/preproxy_users"
files: compat = "no"
Module: Instantiated files (files)
Module: Loaded Acct-Unique-Session-Id
acct_unique: key = "User-Name, Acct-Session-Id,
NAS-IP-Address, Client-IP-Address, NAS-Port"
Module: Instantiated acct_unique (acct_unique)
Module: Loaded detail
detail: detailfile =
"/usr/local/var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d"
detail: detailperm = 384
detail: dirperm = 493
detail: locking = no
Module: Instantiated detail (detail)
Module: Loaded radutmp
radutmp: filename =
"/usr/local/var/log/radius/radutmp"
radutmp: username = "%{User-Name}"
radutmp: case_sensitive = yes
radutmp: check_with_nas = yes
radutmp: perm = 384
radutmp: callerid = yes
Module: Instantiated radutmp (radutmp)
Listening on authentication *:1812
Listening on accounting *:1813
Listening on proxy *:1814
Ready to process requests.
rad_recv: Access-Request packet from host
10.0.1.20:1024, id=227, length=173
Framed-MTU = 1480
NAS-IP-Address = 10.0.1.20
NAS-Identifier = "Lower_Switch"
User-Name = "bob"
Service-Type = Framed-User
Framed-Protocol = PPP
NAS-Port = 2
NAS-Port-Type = Ethernet
NAS-Port-Id = "2"
Called-Station-Id = "00-01-e6-bd-7a-22"
Calling-Station-Id = "00-0f-1f-9e-07-49"
Connect-Info = "CONNECT Ethernet 100Mbps Full
duplex"


CHAP-Password = 0x0200000000000000000000000000000000
Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 0
modcall[authorize]: module "preprocess" returns ok
for request 0
rlm_chap: Setting 'Auth-Type := CHAP'
modcall[authorize]: module "chap" returns ok for
request 0
modcall[authorize]: module "mschap" returns noop for
request 0
rlm_realm: No '@' in User-Name = "bob", 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 bob at 101
radius_xlat: 'Hello, bob'
modcall[authorize]: module "files" returns ok for
request 0
modcall: group authorize returns ok for request 0
rad_check_password: Found Auth-Type MS-CHAP
auth: type "MS-CHAP"
Processing the authenticate section of radiusd.conf
modcall: entering group Auth-Type for request 0
rlm_mschap: No MS-CHAP-Challenge in the request
modcall[authenticate]: module "mschap" returns
reject for request 0
modcall: group Auth-Type returns reject for request 0
auth: Failed to validate the user.
Delaying request 0 for 1 seconds
Finished request 0
Going to the next request
--- Walking the entire request list ---

**********************************


Below is the debug output of the freeradius with
"default_eap_type = peap"


**********************************

[***@localhost root]# radiusd -X
Starting - reading configuration files ...
reread_config: reading radiusd.conf
Config: including file:
/usr/local/etc/raddb/proxy.conf
Config: including file:
/usr/local/etc/raddb/clients.conf
Config: including file:
/usr/local/etc/raddb/snmp.conf
Config: including file:
/usr/local/etc/raddb/eap.conf
Config: including file:
/usr/local/etc/raddb/sql.conf
main: prefix = "/usr/local"
main: localstatedir = "/usr/local/var"
main: logdir = "/usr/local/var/log/radius"
main: libdir = "/usr/local/lib"
main: radacctdir =
"/usr/local/var/log/radius/radacct"
main: hostname_lookups = no
main: max_request_time = 30
main: cleanup_delay = 5
main: max_requests = 1024
main: delete_blocked_requests = 0
main: port = 0
main: allow_core_dumps = no
main: log_stripped_names = no
main: log_file =
"/usr/local/var/log/radius/radius.log"
main: log_auth = no
main: log_auth_badpass = no
main: log_auth_goodpass = no
main: pidfile =
"/usr/local/var/run/radiusd/radiusd.pid"
main: user = "(null)"
main: group = "(null)"
main: usercollide = no
main: lower_user = "no"
main: lower_pass = "no"
main: nospace_user = "no"
main: nospace_pass = "no"
main: checkrad = "/usr/local/sbin/checkrad"
main: proxy_requests = yes
proxy: retry_delay = 5
proxy: retry_count = 3
proxy: synchronous = no
proxy: default_fallback = yes
proxy: dead_time = 120
proxy: post_proxy_authorize = yes
proxy: wake_all_if_all_dead = no
security: max_attributes = 200
security: reject_delay = 1
security: status_server = no
main: debug_level = 0
read_config_files: reading dictionary
read_config_files: reading naslist
Using deprecated naslist file. Support for this will
go away soon.
read_config_files: reading clients
read_config_files: reading realms
radiusd: entering modules setup
Module: Library search path is /usr/local/lib
Module: Loaded exec
exec: wait = yes
exec: program = "(null)"
exec: input_pairs = "request"
exec: output_pairs = "(null)"
exec: packet_type = "(null)"
rlm_exec: Wait=yes but no output defined. Did you mean
output=none?
Module: Instantiated exec (exec)
Module: Loaded expr
Module: Instantiated expr (expr)
Module: Loaded PAP
pap: encryption_scheme = "crypt"
Module: Instantiated pap (pap)
Module: Loaded CHAP
Module: Instantiated chap (chap)
Module: Loaded MS-CHAP
mschap: use_mppe = yes
mschap: require_encryption = yes
mschap: require_strong = yes
mschap: with_ntdomain_hack = yes
mschap: passwd = "(null)"
mschap: authtype = "MS-CHAP"
mschap: ntlm_auth = "(null)"
Module: Instantiated mschap (mschap)
Module: Loaded System
unix: cache = no
unix: passwd = "(null)"
unix: shadow = "(null)"
unix: group = "(null)"
unix: radwtmp = "/usr/local/var/log/radius/radwtmp"
unix: usegroup = no
unix: cache_reload = 600
Module: Instantiated unix (unix)
Module: Loaded eap
eap: default_eap_type = "peap"
eap: timer_expire = 60
eap: ignore_unknown_eap_types = no
eap: cisco_accounting_username_bug = no
rlm_eap: Loaded and initialized type md5
rlm_eap: Loaded and initialized type leap
gtc: challenge = "Password: "
gtc: auth_type = "PAP"
rlm_eap: Loaded and initialized type gtc
tls: rsa_key_exchange = no
tls: dh_key_exchange = yes
tls: rsa_key_length = 512
tls: dh_key_length = 512
tls: verify_depth = 0
tls: CA_path = "(null)"
tls: pem_file_type = yes
tls: private_key_file = "/etc/1x/khurram.pem"
tls: certificate_file = "/etc/1x/khurram.pem"
tls: CA_file = "/etc/1x/root.pem"
tls: private_key_password = "whatever"
tls: dh_file = "/etc/1x/DH"
tls: random_file = "/etc/1x/random"
tls: fragment_size = 1024
tls: include_length = yes
tls: check_crl = no
tls: check_cert_cn = "(null)"
rlm_eap: Loaded and initialized type tls
rlm_eap: No such sub-type for default EAP type peap
radiusd.conf[9]: eap: Module instantiation failed.

*********************************

I hope someone will be able to solve my problem.
Probably I am doing something wrong somewhere.

Thanks in advanced for your help.

Best Regards

//Khurram





_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Alan DeKok]

Post by Khurram Jahangir
I am a new user on this mailing list and I am facing
some problems while trying to use PEAP and freeradius.

Ok...

Post by Khurram Jahangir
modcall: entering group Auth-Type for request 8
rlm_mschap: No MS-CHAP-Challenge in the request

You set "Auth-Type := MS-CHAP". DON'T DO THAT.

Post by Khurram Jahangir
I tried it without mentioning any Auth-Type and then
the server takes it as CHAP by default and it works.

Only if the client sends CHAP requests. If it sends EAP requests,
then EAP would work.

Post by Khurram Jahangir
In eap.conf, under eap, if i change "default_eap_type"
to peap, the I get the following error while running
Radiusd and it crashes
rlm_eap: Loaded and initialized type tls
rlm_eap: No such sub-type for default EAP type peap
radiusd.conf[9]: eap: Module instantiation failed.

Yes... you edited the default "eap.conf" to break it. You put
"peap" and "mschapv2" inside of the "tls" section. They are NOT in
the tls section in the default eap.conf.

Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Khurram Jahangir]

Hi Alan,

Thanks alot for your reply. I really appreciate that
and it was a great help for me. I took off the
Auth-Type := MS-CHAP from the user bob and also
changed the configuration in the HP switch (aaa
authentication port-access eap-radius).

I think I have moved now one step further as I am not
getting the same errors anynoe.

Now the debug log from Radiusd -X shows the following
messages,

--------------------------------------------

[***@localhost root]# radiusd -X
Starting - reading configuration files ...
reread_config: reading radiusd.conf
Config: including file:
/usr/local/etc/raddb/proxy.conf
Config: including file:
/usr/local/etc/raddb/clients.conf
Config: including file:
/usr/local/etc/raddb/snmp.conf
Config: including file:
/usr/local/etc/raddb/eap.conf
Config: including file:
/usr/local/etc/raddb/sql.conf
main: prefix = "/usr/local"
main: localstatedir = "/usr/local/var"
main: logdir = "/usr/local/var/log/radius"
main: libdir = "/usr/local/lib"
main: radacctdir =
"/usr/local/var/log/radius/radacct"
main: hostname_lookups = no
main: max_request_time = 30
main: cleanup_delay = 5
main: max_requests = 1024
main: delete_blocked_requests = 0
main: port = 0
main: allow_core_dumps = no
main: log_stripped_names = no
main: log_file =
"/usr/local/var/log/radius/radius.log"
main: log_auth = no
main: log_auth_badpass = no
main: log_auth_goodpass = no
main: pidfile =
"/usr/local/var/run/radiusd/radiusd.pid"
main: user = "(null)"
main: group = "(null)"
main: usercollide = no
main: lower_user = "no"
main: lower_pass = "no"
main: nospace_user = "no"
main: nospace_pass = "no"
main: checkrad = "/usr/local/sbin/checkrad"
main: proxy_requests = yes
proxy: retry_delay = 5
proxy: retry_count = 3
proxy: synchronous = no
proxy: default_fallback = yes
proxy: dead_time = 120
proxy: post_proxy_authorize = yes
proxy: wake_all_if_all_dead = no
security: max_attributes = 200
security: reject_delay = 1
security: status_server = no
main: debug_level = 0
read_config_files: reading dictionary
read_config_files: reading naslist
Using deprecated naslist file. Support for this will
go away soon.
read_config_files: reading clients
read_config_files: reading realms
radiusd: entering modules setup
Module: Library search path is /usr/local/lib
Module: Loaded exec
exec: wait = yes
exec: program = "(null)"
exec: input_pairs = "request"
exec: output_pairs = "(null)"
exec: packet_type = "(null)"
rlm_exec: Wait=yes but no output defined. Did you mean
output=none?
Module: Instantiated exec (exec)
Module: Loaded expr
Module: Instantiated expr (expr)
Module: Loaded PAP
pap: encryption_scheme = "crypt"
Module: Instantiated pap (pap)
Module: Loaded CHAP
Module: Instantiated chap (chap)
Module: Loaded MS-CHAP
mschap: use_mppe = yes
mschap: require_encryption = yes
mschap: require_strong = yes
mschap: with_ntdomain_hack = yes
mschap: passwd = "(null)"
mschap: authtype = "MS-CHAP"
mschap: ntlm_auth = "(null)"
Module: Instantiated mschap (mschap)
Module: Loaded System
unix: cache = no
unix: passwd = "(null)"
unix: shadow = "(null)"
unix: group = "(null)"
unix: radwtmp = "/usr/local/var/log/radius/radwtmp"
unix: usegroup = no
unix: cache_reload = 600
Module: Instantiated unix (unix)
Module: Loaded eap
eap: default_eap_type = "tls"
eap: timer_expire = 60
eap: ignore_unknown_eap_types = no
eap: cisco_accounting_username_bug = no
rlm_eap: Loaded and initialized type md5
rlm_eap: Loaded and initialized type leap
gtc: challenge = "Password: "
gtc: auth_type = "PAP"
rlm_eap: Loaded and initialized type gtc
tls: rsa_key_exchange = no
tls: dh_key_exchange = yes
tls: rsa_key_length = 512
tls: dh_key_length = 512
tls: verify_depth = 0
tls: CA_path = "(null)"
tls: pem_file_type = yes
tls: private_key_file = "/etc/1x/khurram.pem"
tls: certificate_file = "/etc/1x/khurram.pem"
tls: CA_file = "/etc/1x/root.pem"
tls: private_key_password = "whatever"
tls: dh_file = "/etc/1x/DH"
tls: random_file = "/etc/1x/random"
tls: fragment_size = 1024
tls: include_length = yes
tls: check_crl = no
tls: check_cert_cn = "(null)"
rlm_eap: Loaded and initialized type tls
Module: Instantiated eap (eap)
Module: Loaded preprocess
preprocess: huntgroups =
"/usr/local/etc/raddb/huntgroups"
preprocess: hints = "/usr/local/etc/raddb/hints"
preprocess: with_ascend_hack = no
preprocess: ascend_channels_per_line = 23
preprocess: with_ntdomain_hack = no
preprocess: with_specialix_jetstream_hack = no
preprocess: with_cisco_vsa_hack = no
Module: Instantiated preprocess (preprocess)
Module: Loaded realm
realm: format = "suffix"
realm: delimiter = "@"
realm: ignore_default = no
realm: ignore_null = no
Module: Instantiated realm (suffix)
Module: Loaded files
files: usersfile = "/usr/local/etc/raddb/users"
files: acctusersfile =
"/usr/local/etc/raddb/acct_users"
files: preproxy_usersfile =
"/usr/local/etc/raddb/preproxy_users"
files: compat = "no"
Module: Instantiated files (files)
Module: Loaded Acct-Unique-Session-Id
acct_unique: key = "User-Name, Acct-Session-Id,
NAS-IP-Address, Client-IP-Address, NAS-Port"
Module: Instantiated acct_unique (acct_unique)
Module: Loaded detail
detail: detailfile =
"/usr/local/var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d"
detail: detailperm = 384
detail: dirperm = 493
detail: locking = no
Module: Instantiated detail (detail)
Module: Loaded radutmp
radutmp: filename =
"/usr/local/var/log/radius/radutmp"
radutmp: username = "%{User-Name}"
radutmp: case_sensitive = yes
radutmp: check_with_nas = yes
radutmp: perm = 384
radutmp: callerid = yes
Module: Instantiated radutmp (radutmp)
Listening on authentication *:1812
Listening on accounting *:1813
Listening on proxy *:1814
Ready to process requests.
rad_recv: Access-Request packet from host
10.0.1.20:1024, id=247, length=198
Framed-MTU = 1480
NAS-IP-Address = 10.0.1.20
NAS-Identifier = "Lower_Switch"
User-Name = "bob"
Service-Type = Framed-User
Framed-Protocol = PPP
NAS-Port = 2
NAS-Port-Type = Ethernet
NAS-Port-Id = "2"
Called-Station-Id = "00-01-e6-bd-7a-22"
Calling-Station-Id = "00-0f-1f-9e-07-49"
Connect-Info = "CONNECT Ethernet 100Mbps Full
duplex"
Tunnel-Type:0 = VLAN
Tunnel-Medium-Type:0 = IEEE-802
Tunnel-Private-Group-Id:0 = "30"
EAP-Message = 0x0201000801626f62
Message-Authenticator =
0x2a46e7fe66f05b17259537e545d6abcc



Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 1
modcall[authorize]: module "preprocess" returns ok
for request 1
modcall[authorize]: module "chap" returns noop for
request 1
modcall[authorize]: module "mschap" returns noop for
request 1
rlm_realm: No '@' in User-Name = "bob", looking up
realm NULL
rlm_realm: No such realm "NULL"
modcall[authorize]: module "suffix" returns noop for
request 1
rlm_eap: EAP packet type response id 2 length 6
rlm_eap: No EAP Start, assuming it's an on-going EAP
conversation
modcall[authorize]: module "eap" returns updated for
request 1
users: Matched bob at 100
radius_xlat: 'Hello, bob'
modcall[authorize]: module "files" returns ok for
request 1
modcall: group authorize returns updated for request 1
rad_check_password: Found Auth-Type EAP
auth: type "EAP"
Processing the authenticate section of radiusd.conf
modcall: entering group authenticate for request 1
rlm_eap: Request found, released from the list
rlm_eap: EAP NAK
rlm_eap: EAP-NAK asked for EAP-Type/peap
rlm_eap: No such EAP type peap
rlm_eap: Failed in EAP select
modcall[authenticate]: module "eap" returns invalid
for request 1
modcall: group authenticate returns invalid for
request 1
auth: Failed to validate the user.
Delaying request 1 for 1 seconds

-----------------------------------

I still did not change the eap.conf file as I am not
sure where exactly to add "default_eap_type = peap".

As you suggested in your last message, I should do
"peap" and "mschapv2" inside of TLS. I tried to put
"default_eap_type = peap" under tls like this but I
still got the erros as shown above in Radiusd -X log,

Here is my eap.conf,

eap {

default_eap_type = tls

timer_expire = 60

ignore_unknown_eap_types = no

cisco_accounting_username_bug = no

md5 {
}

leap {
}

gtc {
auth_type = PAP
}

tls {



default_eap_type = peap #### I added this line here ##

private_key_password = whatever
private_key_file = /etc/1x/khurram.pem



certificate_file = /etc/1x/khurram.pem



CA_file = /etc/1x/root.pem



dh_file = /etc/1x/DH
random_file = /etc/1x/random



fragment_size = 1024







peap {

default_eap_type = mschapv2

copy_request_to_tunnel = yes
use_tunneled_reply = no
proxy_tunneled_request_as_eap = yes



}

mschapv2 {
}

}

}


I wonder where exactly should I add this
"default_eap_type = peap" and if "default_eap_type =
mschapv2" is added at the right place in eap.conf or
not. I also am not sure if this is the source of the
problem or not. Your help in this regard will be
highly appreciated.

Best Regards

//Khurram

Post by Khurram Jahangir
I am a new user on this mailing list and I am facing
some problems while trying to use PEAP and

freeradius.

Ok...

Post by Khurram Jahangir
modcall: entering group Auth-Type for request 8
rlm_mschap: No MS-CHAP-Challenge in the request

You set "Auth-Type := MS-CHAP". DON'T DO THAT.

Post by Khurram Jahangir
I tried it without mentioning any Auth-Type and then
the server takes it as CHAP by default and it works.

Only if the client sends CHAP requests. If it sends
EAP requests,
then EAP would work.

Post by Khurram Jahangir
In eap.conf, under eap, if i change

"default_eap_type"

Post by Khurram Jahangir
to peap, the I get the following error while running
Radiusd and it crashes
rlm_eap: Loaded and initialized type tls
rlm_eap: No such sub-type for default EAP type peap
radiusd.conf[9]: eap: Module instantiation failed.

Yes... you edited the default "eap.conf" to break
it. You put
"peap" and "mschapv2" inside of the "tls" section.
They are NOT in
the tls section in the default eap.conf.

Alan DeKok.



_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Josh Howlett]

I have FR set up to auth/acct against MySQL. It appears to work fine in
a high load environment, most of the time.

Very, very occasionally FR appears to mis-process requests from the
NASes.

The NAS will report that an Access-Request has been sent, and an
Access-Accept recieved, but nothing appears to get recorded (either in
detail or SQL accounting) by FreeRADIUS.

We are noticing this because attributes with incorrect values are
getting returned to the NAS.

Even running FR in -X mode fails to catch the incoming/returned packets.
As far as FR is concerned, these sessions never happended.

I'm running out of ideas as to how to trace this problem. Any
suggestions are very welcome! I'm running FR 0.9.3.

josh.

------------------------------------------------------------
Josh Howlett, Networking & Digital Communications,
Information Systems & Computing, University of Bristol, U.K.
'phone: [phone] email: ***@bris.ac.uk
------------------------------------------------------------


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Dustin Doris]

Post by Josh Howlett
I have FR set up to auth/acct against MySQL. It appears to work fine in
a high load environment, most of the time.
Very, very occasionally FR appears to mis-process requests from the
NASes.
The NAS will report that an Access-Request has been sent, and an
Access-Accept recieved, but nothing appears to get recorded (either in
detail or SQL accounting) by FreeRADIUS.

Not seeing it in detail or SQL doesn't neccessarily mean it didn't happen.
That will just record the accounting packets and its possible your NAS
isn't sending the accounting packets on one of these sessions.

Post by Josh Howlett
We are noticing this because attributes with incorrect values are
getting returned to the NAS.
Even running FR in -X mode fails to catch the incoming/returned packets.
As far as FR is concerned, these sessions never happended.

That's wierd. Are you sure the NAS isn't configured with a secondary
radius server that it may be sending these packets to?

Post by Josh Howlett
I'm running out of ideas as to how to trace this problem. Any
suggestions are very welcome! I'm running FR 0.9.3.

You could try enabling detail auth_log and detail reply_log. That will
capture all access request packets as well as all access accept packets
that you send back. These are the actual authentication packets, rather
than the normal detail file/sql that captures accounting. This would help
you troubleshoot this.

Hope that helps.

-Dusty Doris

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Josh Howlett]

--On Thursday, October 07, 2004 16:27:10 -0400 Dustin Doris

Post by Dustin Doris

Post by Josh Howlett
I have FR set up to auth/acct against MySQL. It appears to work fine in
a high load environment, most of the time.
Very, very occasionally FR appears to mis-process requests from the
NASes.

<snip>

Post by Dustin Doris

Post by Josh Howlett
Even running FR in -X mode fails to catch the incoming/returned packets.
As far as FR is concerned, these sessions never happended.

That's wierd. Are you sure the NAS isn't configured with a secondary
radius server that it may be sending these packets to?

No secondary server...

This is only happening with a very tiny % of requests.

Post by Dustin Doris

Post by Josh Howlett
I'm running out of ideas as to how to trace this problem. Any
suggestions are very welcome! I'm running FR 0.9.3.

You could try enabling detail auth_log and detail reply_log. That will
capture all access request packets as well as all access accept packets
that you send back. These are the actual authentication packets, rather
than the normal detail file/sql that captures accounting. This would help
you troubleshoot this.

I've done that too - and there's no record of the incoming RADIUS
transaction, yet the NAS sees it!

Thanks for the suggestions.

best regards, josh.

[Alan DeKok]

Post by Josh Howlett
I've done that too - and there's no record of the incoming RADIUS
transaction, yet the NAS sees it!

Run tcpdump on the network. I'd bet that the packets are going to a
different IP and/or port.

If the packets aren't seen in the debug log or in the detail files,
then the server isn't receiving them.

Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Josh Howlett]

Post by Alan DeKok

Post by Josh Howlett
I've done that too - and there's no record of the incoming RADIUS
transaction, yet the NAS sees it!

Run tcpdump on the network. I'd bet that the packets are going to a
different IP and/or port.

I'm doing that, matching packets to & from udp/1812.

Post by Alan DeKok
If the packets aren't seen in the debug log or in the detail files,
then the server isn't receiving them.

That's what I would be inclined to believe ordinarily, but the NASes' logs
say otherwise :-/

thanks, josh.

[Josh Howlett]

Post by Alan DeKok

Post by Josh Howlett
I've done that too - and there's no record of the incoming RADIUS
transaction, yet the NAS sees it!

Run tcpdump on the network. I'd bet that the packets are going to a
different IP and/or port.

Here you go:

14:10:08.344582 192.168.1.208.60615 > 192.168.1.202.1812:
rad-access-req 72 [id 83] Attr[ User{A} Pass Framed_ipaddr{X} ] (DF)
14:10:08.382423 192.168.1.202.1812 > 192.168.1.208.60615:
rad-access-accept 32 [id 83] Attr[ Reply{8} Vendor_specific{} ] (DF)

14:10:08.641964 192.168.1.208.60615 > 192.168.1.202.1812:
rad-access-req 69 [id 83] Attr[ User{B} Pass Framed_ipaddr{Y} [|radius] (DF)
14:10:08.642038 192.168.1.202.1812 > 192.168.1.208.60615:
rad-access-accept 32 [id 83] Attr[ Reply{8} Vendor_specific{} ] (DF)

The first request is processed correctly. The second request is not; it
contains the wrong Reply-Message and VSA values. It is also not logged,
either in detail (auth, reply), or in -X output.

In fact, the returned attributes in the second Access-Accept are the
same as the first (when they should have been different).

I am speculating here, but it is possible that FR has gotten confused by
the fact that each Access-Request bears the same source IP:port and ID
field, and is returning a duplicate Access-Accept?

many thanks, josh.

------------------------------------------------------------
Josh Howlett, Networking & Digital Communications,
Information Systems & Computing, University of Bristol, U.K.
'phone: [phone] email: ***@bris.ac.uk
------------------------------------------------------------


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Alan DeKok]

Post by Josh Howlett
In fact, the returned attributes in the second Access-Accept are the
same as the first (when they should have been different).
I am speculating here, but it is possible that FR has gotten confused by
the fact that each Access-Request bears the same source IP:port and ID
field, and is returning a duplicate Access-Accept?

Ah, that's what I suspected.

The NAS is probably re-using the same authentication vector (try
tcpdump -x, or ethereal to see it). In that case, with:

- same ID
- same packet type
- same authentication vector

The server MUST respond with the same reply packet as of a few
seconds ago.

What is your NAS? If it's radclient, then there's a bug in it which
may cause that problem.

Alan DeKok.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Josh Howlett]

Post by Alan DeKok

Post by Josh Howlett
In fact, the returned attributes in the second Access-Accept are the
same as the first (when they should have been different).
I am speculating here, but it is possible that FR has gotten confused by
the fact that each Access-Request bears the same source IP:port and ID
field, and is returning a duplicate Access-Accept?

Ah, that's what I suspected.
The NAS is probably re-using the same authentication vector (try
- same ID
- same packet type
- same authentication vector
The server MUST respond with the same reply packet as of a few
seconds ago.

What's an 'authentication vector'? Is this the packet authenticator?

thanks, josh.

------------------------------------------------------------
Josh Howlett, Networking & Digital Communications,
Information Systems & Computing, University of Bristol, U.K.
'phone: [phone] email: ***@bris.ac.uk
------------------------------------------------------------


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Josh Howlett]

Post by Josh Howlett

Post by Alan DeKok

Post by Josh Howlett
In fact, the returned attributes in the second Access-Accept are the
same as the first (when they should have been different).
I am speculating here, but it is possible that FR has gotten confused by
the fact that each Access-Request bears the same source IP:port and ID
field, and is returning a duplicate Access-Accept?

Ah, that's what I suspected.
The NAS is probably re-using the same authentication vector (try
- same ID
- same packet type
- same authentication vector
The server MUST respond with the same reply packet as of a few
seconds ago.

What's an 'authentication vector'? Is this the packet authenticator?

Replying to my own mail - the Authenticators are the same in both
packets.

So is this definitely a NAS bug? From my reading of the Authn RFC, the
Authenticator should be unique...

thanks for your help Alan.

josh.

------------------------------------------------------------
Josh Howlett, Networking & Digital Communications,
Information Systems & Computing, University of Bristol, U.K.
'phone: [phone] email: ***@bris.ac.uk
------------------------------------------------------------


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Zohaib Tariq]

Hi all,

can anyone share cisco 5300 configuration that can work with freeradius
server.

Thanks

Tariq


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[jc]

Post by Zohaib Tariq
can anyone share cisco 5300 configuration that can work with freeradius
server.

not quite sure what you after, since 5300 wouldnt care about which
software or platform you use to authorize your users.

its all a matter of correctly setting up you as5300 to handle radius
requests ito authentication, authorization and accounting. again, the only
part freeradius will play a role would be accounting attributes (values)
as specified in your cisco dictionary files..

i suggest having a look at documentation that you can find on cisco.com ..
wouldnt be such a bad idea to find the cookbook for the specific IOS
strain that you want to use.

http://www.cisco.com/en/US/products/hw/univgate/ps501/products_quick_start09186a00800a4c7c.html
http://www.cisco.com/en/US/products/sw/iosswrel/ps1830/products_feature_guide09186a00800879e8.html

hth

j.






#include <std-disclaimer.h> - 'save the trees, send an email'



-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Alan DeKok]

Post by Josh Howlett
Replying to my own mail - the Authenticators are the same in both
packets.
So is this definitely a NAS bug? From my reading of the Authn RFC, the
Authenticator should be unique...

Yes. The NAS is broken.

It *may* be possible to work around it a little, with hacks to the
server. But I'm not sure I'd recommend that.

Alan DeKok.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Josh Howlett]

Post by Alan DeKok

Post by Josh Howlett
Replying to my own mail - the Authenticators are the same in both
packets.
So is this definitely a NAS bug? From my reading of the Authn RFC, the
Authenticator should be unique...

Yes. The NAS is broken.
It *may* be possible to work around it a little, with hacks to the
server. But I'm not sure I'd recommend that.

That's what I figured too.

Could I request that FreeRADIUS logs an error message when this condition
occurs (ie. a reply is generated on basis of src IP/port & authenticator)?
The lack of any logging information at all (even at -X level) made this
very difficult to trace...

Thanks for your help with this.

josh.

[Alan DeKok]

Post by Josh Howlett
Could I request that FreeRADIUS logs an error message when this condition
occurs (ie. a reply is generated on basis of src IP/port & authenticator)?
The lack of any logging information at all (even at -X level) made this

In debugging mode, the server says "sending duplicate reply to
client t...". I'm not sure if it's logged, but I don't see why it
couldn't be.

See src/main'/radiusd.c.

Alan DeKok.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Alan DeKok]

Post by Khurram Jahangir
I still did not change the eap.conf file as I am not
sure where exactly to add "default_eap_type = peap".

Uh, no. I told you what was wrong, and how to fix it.

Post by Khurram Jahangir
As you suggested in your last message, I should do
"peap" and "mschapv2" inside of TLS.

Huh? I said to do the COMPLETE OPPOSITE.

Post by Khurram Jahangir
Here is my eap.conf,

...

which is pretty much exactly the same as you had before.

Post by Khurram Jahangir
tls {
default_eap_type = peap #### I added this line here ##

I fail to see why.

Post by Khurram Jahangir
I wonder where exactly should I add this
"default_eap_type = peap"

Read "eap.conf". It has examples of "default_eap_type", and they
aren't located where you put it.

Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Khurram Jahangir]

Hi Again,

Sorry it was my mistake and i changed the the eap.conf
file back (the brackets were messed up actually) and
now it is working fine.

Thanks for your help. I found this mailing list to be
very useful.

Regards

//khurram

Post by Khurram Jahangir

Post by Khurram Jahangir
I still did not change the eap.conf file as I am

not

Post by Khurram Jahangir
sure where exactly to add "default_eap_type =

peap".
Uh, no. I told you what was wrong, and how to fix
it.

Post by Khurram Jahangir
As you suggested in your last message, I should do
"peap" and "mschapv2" inside of TLS.

Huh? I said to do the COMPLETE OPPOSITE.

Post by Khurram Jahangir
Here is my eap.conf,

...
which is pretty much exactly the same as you had
before.

Post by Khurram Jahangir
tls {
default_eap_type = peap #### I added this line

here ##
I fail to see why.

Post by Khurram Jahangir
I wonder where exactly should I add this
"default_eap_type = peap"

Read "eap.conf". It has examples of
"default_eap_type", and they
aren't located where you put it.
Alan DeKok.
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html

__________________________________
Do you Yahoo!?
Y! Messenger - Communicate in real time. Download now.
http://messenger.yahoo.com

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html