Re: PEAP mschapv2 Proxy not working.
The virtual_server = inner-tunnel seems to have done the trick. Thanks for your help. -andrew Dmitry Sergienko wrote: Hi! If you still have no luck with 1.1.7 proxying mschapv2, try to move to 2.0.1 with patches in event.c discussed yesterday in freeradius-users. I'm trying to do the same authentication - extract MS-CHAPv2 from PEAP and authorize inner request against external RADIUS server. With 2.0.1 and a patch at least eapol_test passes authorization. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: PEAP mschapv2 Proxy not working.
Hi! If you still have no luck with 1.1.7 proxying mschapv2, try to move to 2.0.1 with patches in event.c discussed yesterday in freeradius-users. I'm trying to do the same authentication - extract MS-CHAPv2 from PEAP and authorize inner request against external RADIUS server. With 2.0.1 and a patch at least eapol_test passes authorization. Andrew Olson wrote: Hello, I'm having trouble getting freeradius-1.1.7 to proxy PEAP-mshcapv2 to another RADIUS server. My other server doesn't do EAP, so I'm just sending mschapv2 achieved with proxy_tunneled_request_as_eap = no in eap.conf. When I proxy to my other server, I get back an Access-Accept packet. Then, freeradius sends an Access Challenge to the client, receives a response and then things appear to break. I am able to successfully authenticate users with PEAP by defining them locally in the users file. Additionally, I have gotten TTLS to work by proxying to another server, it's just PEAP that I'm having problems with. The differing line in the debug seems to be: proxied eaptls_process returned 7 rlm_eap_peap: EAPTLS_OK rlm_eap_peap: Session established. Decoding tunneled attributes. rlm_eap_peap: EAP type mschapv2 -vs- non-proxied eaptls_process returned 7 rlm_eap_peap: EAPTLS_OK rlm_eap_peap: Session established. Decoding tunneled attributes. rlm_eap_peap: Received EAP-TLV response. I'm running a pretty standard config, I think. I can send copies of it, if that would help. Thanks, Andrew Olson The complete proxied debug starting with the Access-Request is as follows: Sending Access-Request of id 0 to 198.82.247.36 port 1812 User-Name = anolson NAS-IP-Address := 198.82.245.57 MS-CHAP-Challenge = 0x85feba9cbed9e9191bf72a29f0f82312 MS-CHAP2-Response = 0x0700b776d1433b4d6dab43d5bde9163e8b45ee7fcb070f3766e7e7b0f198b72754b44a9ef0255d712db1 Proxy-State = 0x3136 Service-Type := Framed-User Waking up in 6 seconds... rad_recv: Access-Accept packet from host 198.82.247.36:1812, id=0, length=189 Filter-Id = CNS_NET1 MS-CHAP2-Success = 0x07533d4343304142444332354233304645314131394238363737413941334136454631364134454634 MS-MPPE-Send-Key = 0x7b5fcacde0c3798261894df701a5cdd5 MS-MPPE-Recv-Key = 0x3900c03d5b5851da66e8fb27d90077f9 MS-MPPE-Encryption-Policy = 0x0001 MS-MPPE-Encryption-Types = 0x000e Processing the post-proxy section of radiusd.conf modcall: entering group post-proxy for request 6 PEAP: Passing reply from proxy back into the tunnel. PEAP: Passing reply back for EAP-MS-CHAP-V2 0x8170500 2 Processing the post-proxy section of radiusd.conf modcall: entering group post-proxy for request 6 rlm_eap_mschapv2: Passing reply from proxy back into the tunnel 0x8170500 2. rlm_eap_mschapv2: Authentication succeeded. MSCHAP Success modcall[post-proxy]: module eap returns ok for request 6 modcall: leaving group post-proxy (returns ok) for request 6 POST-PROXY 2 POST-AUTH 2 PEAP: Got reply 11 PEAP: Got tunneled Access-Challenge PEAP: Reply was handled modcall[post-proxy]: module eap returns ok for request 6 modcall: leaving group post-proxy (returns ok) for request 6 Sending Access-Challenge of id 16 to 128.173.10.131 port 56945 EAP-Message = 0x0107005b190017030100502c303c60e1337bcb4c17a281f71910d23777fd5f4a4d5aefab92a23ff28a993aa17ebc2d6bd7567b9386fec7c4e6f2f7ae4c4655a8492000e0e473fc7e8be63a1bf372449cba9f795dc6535b04648cdb Message-Authenticator = 0x State = 0x23a96486ec5dbd008e1eddcee31dfa93 Finished request 6 Going to the next request Waking up in 6 seconds... rad_recv: Access-Request packet from host 128.173.10.131:56945, id=17, length=151 User-Name = anolson State = 0x23a96486ec5dbd008e1eddcee31dfa93 EAP-Message = 0x020700541980004e170301002050f4490743b89308d9bb84f411a1629e7b6f06dd6c02c2525747560f657f63d117030100209d0c853d82e17d05938ab49201447c135a90d068d1641a23db5fc04cfcc0dd08 Message-Authenticator = 0x3c828120c544cde1b5d4366b7e735350 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 7 modcall[authorize]: module preprocess returns ok for request 7 modcall[authorize]: module chap returns noop for request 7 modcall[authorize]: module mschap returns noop for request 7 rlm_realm: No '@' in User-Name = anolson, looking up realm NULL rlm_realm: No such realm NULL modcall[authorize]: module suffix returns noop for request 7 rlm_eap: EAP packet type response id 7 length 84 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module eap returns updated for request 7 modcall[authorize]: module files returns notfound for request 7 modcall: leaving group authorize (returns updated) for request 7 rad_check_password: Found Auth-Type EAP auth: type EAP Processing the
Re: PEAP mschapv2 Proxy not working.
I got 2.0.1 patched, compiled and configured. I'm still seeing the same behaving listed below. Could it be something with my config. I'm simply doing: DEFAULT FreeRADIUS-Proxied-To == 127.0.0.1, Proxy-To-Realm := realm Thanks, Andrew Olson Dmitry Sergienko wrote: Hi! If you still have no luck with 1.1.7 proxying mschapv2, try to move to 2.0.1 with patches in event.c discussed yesterday in freeradius-users. I'm trying to do the same authentication - extract MS-CHAPv2 from PEAP and authorize inner request against external RADIUS server. With 2.0.1 and a patch at least eapol_test passes authorization. Andrew Olson wrote: Hello, I'm having trouble getting freeradius-1.1.7 to proxy PEAP-mshcapv2 to another RADIUS server. My other server doesn't do EAP, so I'm just sending mschapv2 achieved with proxy_tunneled_request_as_eap = no in eap.conf. When I proxy to my other server, I get back an Access-Accept packet. Then, freeradius sends an Access Challenge to the client, receives a response and then things appear to break. I am able to successfully authenticate users with PEAP by defining them locally in the users file. Additionally, I have gotten TTLS to work by proxying to another server, it's just PEAP that I'm having problems with. The differing line in the debug seems to be: proxied eaptls_process returned 7 rlm_eap_peap: EAPTLS_OK rlm_eap_peap: Session established. Decoding tunneled attributes. rlm_eap_peap: EAP type mschapv2 -vs- non-proxied eaptls_process returned 7 rlm_eap_peap: EAPTLS_OK rlm_eap_peap: Session established. Decoding tunneled attributes. rlm_eap_peap: Received EAP-TLV response. I'm running a pretty standard config, I think. I can send copies of it, if that would help. Thanks, Andrew Olson - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: PEAP mschapv2 Proxy not working.
Inner request for PEAP is EAP-MSCHAPv2 not MSCHAPv2. Ivan Kalik Kalik Informatika ISP Dana 6/2/2008, Andrew Olson [EMAIL PROTECTED] piše: I got 2.0.1 patched, compiled and configured. I'm still seeing the same behaving listed below. Could it be something with my config. I'm simply doing: DEFAULT FreeRADIUS-Proxied-To == 127.0.0.1, Proxy-To-Realm := realm Thanks, Andrew Olson Dmitry Sergienko wrote: Hi! If you still have no luck with 1.1.7 proxying mschapv2, try to move to 2.0.1 with patches in event.c discussed yesterday in freeradius-users. I'm trying to do the same authentication - extract MS-CHAPv2 from PEAP and authorize inner request against external RADIUS server. With 2.0.1 and a patch at least eapol_test passes authorization. Andrew Olson wrote: Hello, I'm having trouble getting freeradius-1.1.7 to proxy PEAP-mshcapv2 to another RADIUS server. My other server doesn't do EAP, so I'm just sending mschapv2 achieved with proxy_tunneled_request_as_eap = no in eap.conf. When I proxy to my other server, I get back an Access-Accept packet. Then, freeradius sends an Access Challenge to the client, receives a response and then things appear to break. I am able to successfully authenticate users with PEAP by defining them locally in the users file. Additionally, I have gotten TTLS to work by proxying to another server, it's just PEAP that I'm having problems with. The differing line in the debug seems to be: proxied eaptls_process returned 7 rlm_eap_peap: EAPTLS_OK rlm_eap_peap: Session established. Decoding tunneled attributes. rlm_eap_peap: EAP type mschapv2 -vs- non-proxied eaptls_process returned 7 rlm_eap_peap: EAPTLS_OK rlm_eap_peap: Session established. Decoding tunneled attributes. rlm_eap_peap: Received EAP-TLV response. I'm running a pretty standard config, I think. I can send copies of it, if that would help. Thanks, Andrew Olson - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: PEAP mschapv2 Proxy not working.
Hi!
Andrew Olson wrote:
I got 2.0.1 patched, compiled and configured. I'm still seeing the same
behaving listed below. Could it be something with my config.
I'm simply doing:
DEFAULT FreeRADIUS-Proxied-To == 127.0.0.1, Proxy-To-Realm := realm
You don't need this if you set virtual-server = proxy-inner-tunnel in eap.conf
- eap -
peap.
proxy-inner-tunnel should look as following:
server proxy-inner-tunnel {
authorize {
update control {
Proxy-To-Realm := place_the_name_of_your_realm_here
}
}
authenticate {
eap
}
}
And this is my part of eap.conf:
peap {
default_eap_type = mschapv2
copy_request_to_tunnel = yes
use_tunneled_reply = no
proxy_tunneled_request_as_eap = no
virtual_server = proxy-inner-tunnel
}
users file is empty at all.
If this doesn't help please share your debug output.
--
Best regards,
Dmitry Sergienko
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
PEAP mschapv2 Proxy not working.
Hello, I'm having trouble getting freeradius-1.1.7 to proxy PEAP-mshcapv2 to another RADIUS server. My other server doesn't do EAP, so I'm just sending mschapv2 achieved with proxy_tunneled_request_as_eap = no in eap.conf. When I proxy to my other server, I get back an Access-Accept packet. Then, freeradius sends an Access Challenge to the client, receives a response and then things appear to break. I am able to successfully authenticate users with PEAP by defining them locally in the users file. Additionally, I have gotten TTLS to work by proxying to another server, it's just PEAP that I'm having problems with. The differing line in the debug seems to be: proxied eaptls_process returned 7 rlm_eap_peap: EAPTLS_OK rlm_eap_peap: Session established. Decoding tunneled attributes. rlm_eap_peap: EAP type mschapv2 -vs- non-proxied eaptls_process returned 7 rlm_eap_peap: EAPTLS_OK rlm_eap_peap: Session established. Decoding tunneled attributes. rlm_eap_peap: Received EAP-TLV response. I'm running a pretty standard config, I think. I can send copies of it, if that would help. Thanks, Andrew Olson The complete proxied debug starting with the Access-Request is as follows: Sending Access-Request of id 0 to 198.82.247.36 port 1812 User-Name = anolson NAS-IP-Address := 198.82.245.57 MS-CHAP-Challenge = 0x85feba9cbed9e9191bf72a29f0f82312 MS-CHAP2-Response = 0x0700b776d1433b4d6dab43d5bde9163e8b45ee7fcb070f3766e7e7b0f198b72754b44a9ef0255d712db1 Proxy-State = 0x3136 Service-Type := Framed-User Waking up in 6 seconds... rad_recv: Access-Accept packet from host 198.82.247.36:1812, id=0, length=189 Filter-Id = CNS_NET1 MS-CHAP2-Success = 0x07533d4343304142444332354233304645314131394238363737413941334136454631364134454634 MS-MPPE-Send-Key = 0x7b5fcacde0c3798261894df701a5cdd5 MS-MPPE-Recv-Key = 0x3900c03d5b5851da66e8fb27d90077f9 MS-MPPE-Encryption-Policy = 0x0001 MS-MPPE-Encryption-Types = 0x000e Processing the post-proxy section of radiusd.conf modcall: entering group post-proxy for request 6 PEAP: Passing reply from proxy back into the tunnel. PEAP: Passing reply back for EAP-MS-CHAP-V2 0x8170500 2 Processing the post-proxy section of radiusd.conf modcall: entering group post-proxy for request 6 rlm_eap_mschapv2: Passing reply from proxy back into the tunnel 0x8170500 2. rlm_eap_mschapv2: Authentication succeeded. MSCHAP Success modcall[post-proxy]: module eap returns ok for request 6 modcall: leaving group post-proxy (returns ok) for request 6 POST-PROXY 2 POST-AUTH 2 PEAP: Got reply 11 PEAP: Got tunneled Access-Challenge PEAP: Reply was handled modcall[post-proxy]: module eap returns ok for request 6 modcall: leaving group post-proxy (returns ok) for request 6 Sending Access-Challenge of id 16 to 128.173.10.131 port 56945 EAP-Message = 0x0107005b190017030100502c303c60e1337bcb4c17a281f71910d23777fd5f4a4d5aefab92a23ff28a993aa17ebc2d6bd7567b9386fec7c4e6f2f7ae4c4655a8492000e0e473fc7e8be63a1bf372449cba9f795dc6535b04648cdb Message-Authenticator = 0x State = 0x23a96486ec5dbd008e1eddcee31dfa93 Finished request 6 Going to the next request Waking up in 6 seconds... rad_recv: Access-Request packet from host 128.173.10.131:56945, id=17, length=151 User-Name = anolson State = 0x23a96486ec5dbd008e1eddcee31dfa93 EAP-Message = 0x020700541980004e170301002050f4490743b89308d9bb84f411a1629e7b6f06dd6c02c2525747560f657f63d117030100209d0c853d82e17d05938ab49201447c135a90d068d1641a23db5fc04cfcc0dd08 Message-Authenticator = 0x3c828120c544cde1b5d4366b7e735350 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 7 modcall[authorize]: module preprocess returns ok for request 7 modcall[authorize]: module chap returns noop for request 7 modcall[authorize]: module mschap returns noop for request 7 rlm_realm: No '@' in User-Name = anolson, looking up realm NULL rlm_realm: No such realm NULL modcall[authorize]: module suffix returns noop for request 7 rlm_eap: EAP packet type response id 7 length 84 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module eap returns updated for request 7 modcall[authorize]: module files returns notfound for request 7 modcall: leaving group authorize (returns updated) for request 7 rad_check_password: Found Auth-Type EAP auth: type EAP 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/peap rlm_eap: processing type peap rlm_eap_peap: Authenticate rlm_eap_tls: processing TLS rlm_eap_tls: Length Included eaptls_verify returned 11 eaptls_process returned 7 rlm_eap_peap: EAPTLS_OK rlm_eap_peap:
