EAP-PEAP-MSCHAPv2: use_tunneled_reply = yes
Bjarni Hardarson
freeradius at hardarson.se
Fri Sep 30 14:51:25 CEST 2005
Hi all,
I'm using FreeRADIUS with Cisco 1200 Series Access points for dynamic VLAN
assignment.
When i set use_tunneled_reply = yes for PEAP i get an Access-Challenge with
the correct attributes but the final Access-Accept has no attributes and the
User-Name is the anonymous one from the outer tunnel. This username is then
used by the AP for accounting.
Is this by design or is my configuration wrong?
Partial debug,
Processing the authenticate section of radiusd.conf
modcall: entering group authenticate for request 24
rlm_eap: Request found, released from the list
rlm_eap: EAP/mschapv2
rlm_eap: processing type mschapv2
rlm_eap: Freeing handler
modcall[authenticate]: module "eap" returns ok for request 24
modcall: group authenticate returns ok for request 24
PEAP: Got tunneled reply RADIUS code 2
User-Name = "radtest"
Tunnel-Private-Group-Id:0 = "310"
Tunnel-Medium-Type:0 = IEEE-802
Tunnel-Type:0 = VLAN
EAP-Message = 0x03080004
Message-Authenticator = 0x00000000000000000000000000000000
PEAP: Processing from tunneled session code 0x818f508 2
User-Name = "radtest"
Tunnel-Private-Group-Id:0 = "310"
Tunnel-Medium-Type:0 = IEEE-802
Tunnel-Type:0 = VLAN
EAP-Message = 0x03080004
Message-Authenticator = 0x00000000000000000000000000000000
PEAP: Tunneled authentication was successful.
rlm_eap_peap: SUCCESS
modcall[authenticate]: module "eap" returns handled for request 24
modcall: group authenticate returns handled for request 24 Sending
Access-Challenge of id 8 to 127.0.0.1:33229
User-Name = "radtest"
Tunnel-Private-Group-Id:0 = "310"
Tunnel-Medium-Type:0 = IEEE-802
Tunnel-Type:0 = VLAN
Message-Authenticator = 0x00000000000000000000000000000000
EAP-Message =
0x010900501900170301002079fdf7026cf88ffd8c978e4fb62290b4d4f4a1596c767f557ada
bdaf51b7437d17030100209a1de8e9b88b4654d03b0754d4f5a04887b57b329c94a6494ef84d
2bf74f294c
State = 0x3c86d1f16a6312263ae7a01dbfc81a28
Finished request 24
Going to the next request
Waking up in 6 seconds...
rad_recv: Access-Request packet from host 127.0.0.1:33229, id=9, length=205
User-Name = "anon"
NAS-IP-Address = 127.0.0.1
Calling-Station-Id = "00-00-00-00-00-02"
Framed-MTU = 1400
NAS-Port-Type = Wireless-802.11
Connect-Info = "CONNECT 11Mbps 802.11b"
EAP-Message =
0x0209005019001703010020f8f585176e2220ba00055d66cd73494a9539cce8d52da81ff067
f5835fd4de1117030100207461f938bb9af8c154f926ab2eb5653392cb1ebb02782ac58c3b6c
ca8566fbdd
State = 0x3c86d1f16a6312263ae7a01dbfc81a28
Message-Authenticator = 0x830975610af464574e583a2a9240068d
Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 25
modcall[authorize]: module "preprocess" returns ok for request 25
radius_xlat: '/var/log/radiusd/radiusd-20050930'
rlm_detail: /var/log/radiusd/radiusd-%Y%m%d expands to
/var/log/radiusd/radiusd-20050930
modcall[authorize]: module "auth_log" returns ok for request 25
modcall[authorize]: module "chap" returns noop for request 25
modcall[authorize]: module "mschap" returns noop for request 25
rlm_realm: No '@' in User-Name = "anon", looking up realm NULL
rlm_realm: No such realm "NULL"
modcall[authorize]: module "suffix" returns noop for request 25
rlm_eap: EAP packet type response id 9 length 80
rlm_eap: No EAP Start, assuming it's an on-going EAP conversation
modcall[authorize]: module "eap" returns updated for request 25
modcall[authorize]: module "files" returns notfound for request 25
modcall: group authorize returns updated for request 25
rad_check_password: Found Auth-Type EAP
auth: type "EAP"
Processing the authenticate section of radiusd.conf
modcall: entering group authenticate for request 25
rlm_eap: Request found, released from the list
rlm_eap: EAP/peap
rlm_eap: processing type peap
rlm_eap_peap: Authenticate
rlm_eap_tls: processing TLS
eaptls_verify returned 7
rlm_eap_tls: Done initial handshake
eaptls_process returned 7
rlm_eap_peap: EAPTLS_OK
rlm_eap_peap: Session established. Decoding tunneled attributes.
rlm_eap_peap: Received EAP-TLV response.
rlm_eap_peap: Tunneled data is valid.
rlm_eap_peap: Success
rlm_eap: Freeing handler
modcall[authenticate]: module "eap" returns ok for request 25
modcall: group authenticate returns ok for request 25
Sending Access-Accept of id 9 to 127.0.0.1:33229
MS-MPPE-Recv-Key =
0x73f9e4f3cc50836d0d52db55ddceb6afb7fea6e50313380873101fe245e6532d
MS-MPPE-Send-Key =
0xcbf30f484d74cc947dcd0ea4fb49f7d94adb6be677e23d4edae3a22d136ad3b9
EAP-Message = 0x03090004
Message-Authenticator = 0x00000000000000000000000000000000
User-Name = "anon"
Finished request 25
Going to the next request
Waking up in 6 seconds...
--- Walking the entire request list ---
Cleaning up request 16 ID 0 with timestamp 433d25b6
Cleaning up request 17 ID 1 with timestamp 433d25b6
Cleaning up request 18 ID 2 with timestamp 433d25b6
Cleaning up request 19 ID 3 with timestamp 433d25b6
Cleaning up request 20 ID 4 with timestamp 433d25b6
Cleaning up request 21 ID 5 with timestamp 433d25b6
Cleaning up request 22 ID 6 with timestamp 433d25b6
Cleaning up request 23 ID 7 with timestamp 433d25b6
Cleaning up request 24 ID 8 with timestamp 433d25b6
Cleaning up request 25 ID 9 with timestamp 433d25b6
Nothing to do. Sleeping until we see a request.
---------------------------------------------------
When i use TTLS everything works perfectly.
If i set use_tunneled_reply = no for TTLS the outer tunnel identity is used
in the Access-Accept and no attributes are returned.
Partial debug,
Processing the authenticate section of radiusd.conf
modcall: entering group authenticate for request 7
rlm_eap: Request found, released from the list
rlm_eap: EAP/mschapv2
rlm_eap: processing type mschapv2
rlm_eap: Freeing handler
modcall[authenticate]: module "eap" returns ok for request 7
modcall: group authenticate returns ok for request 7
TTLS: Got tunneled reply RADIUS code 2
User-Name = "radtest"
Tunnel-Private-Group-Id:0 = "310"
Tunnel-Medium-Type:0 = IEEE-802
Tunnel-Type:0 = VLAN
EAP-Message = 0x03070004
Message-Authenticator = 0x00000000000000000000000000000000
TTLS: Got tunneled Access-Accept
rlm_eap: Freeing handler
TTLS: Freeing handler for user radtes
modcall[authenticate]: module "eap" returns ok for request 7
modcall: group authenticate returns ok for request 7
Sending Access-Accept of id 7 to 127.0.0.1:33227
User-Name = "radtest"
Tunnel-Private-Group-Id:0 = "310"
Tunnel-Medium-Type:0 = IEEE-802
Tunnel-Type:0 = VLAN
Message-Authenticator = 0x00000000000000000000000000000000
MS-MPPE-Recv-Key =
0xf250fa51ea382aef2f2ea5ebaab8596fa822cf6788ccd2782fe2e7df98cd06aa
MS-MPPE-Send-Key =
0xca164c1041c8b439c99b13505ba04aaf48cabf6802df8c92738a2c12349b4be2
EAP-Message = 0x03070004
Finished request 7
Going to the next request
Waking up in 6 seconds...
--- Walking the entire request list ---
Cleaning up request 0 ID 0 with timestamp 433d1f58
Cleaning up request 1 ID 1 with timestamp 433d1f58
Cleaning up request 2 ID 2 with timestamp 433d1f58
Cleaning up request 3 ID 3 with timestamp 433d1f58
Cleaning up request 4 ID 4 with timestamp 433d1f58
Cleaning up request 5 ID 5 with timestamp 433d1f58
Cleaning up request 6 ID 6 with timestamp 433d1f58
Cleaning up request 7 ID 7 with timestamp 433d1f58
Nothing to do. Sleeping until we see a request.
raddb/eap.conf
eap {
default_eap_type = peap
timer_expire = 60
ignore_unknown_eap_types = no
cisco_accounting_username_bug = no
tls {
private_key_password = ********
private_key_file = ${raddbdir}/certs/srv_key.pem
certificate_file = ${raddbdir}/certs/srv_cert.pem
CA_file = ${raddbdir}/certs/demoCA/prv.pem
dh_file = ${raddbdir}/certs/dh
random_file = /dev/urandom
}
ttls {
default_eap_type = mschapv2
copy_request_to_tunnel = no
use_tunneled_reply = yes
}
mschapv2 {
}
peap {
default_eap_type = mschapv2
copy_request_to_tunnel = no
use_tunneled_reply = yes
}
mschapv2 {
}
}
raddb/users
DEFAULT FreeRADIUS-Proxied-To == 127.0.0.1
User-Name = "%{User-Name}",
Fall-Through = Yes
DEFAULT Huntgroup-name == "LAN", FreeRADIUS-Proxied-To == 127.0.0.1,
Autz-Type := LAN
DEFAULT Huntgroup-name == "AIR", FreeRADIUS-Proxied-To == 127.0.0.1,
Autz-Type := AIR
More information about the Freeradius-Users
mailing list