Re: PEAP/MSCHAPv2 problem
Looking at the output, things become clearer. The conversation ends when the server tries to send the first Access-Challenge packet to the client. It seems like that packet never gets there - and so the client retransmits the same Request over and over again. The server then repeatedly tries to re-send its reply, but again, it never seems to get there. Make sure that the changed IP address doesn't lead to some firewall (host FW? net FW? Cisco Controller's ACLs?) eats the responses. I checked with wireshark, requests were send, but no response. This was the point. An ACL blocked traffic back to the wlc. Thanks al lot for your help :-) Greetings, Juergen - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: PEAP/MSCHAPv2 problem
Am 05.04.2011 07:31, schrieb Stefan Winter: Hi, The solution to the problem is simple. The answer is in front of you. Alan DeKok. Looks like i'm blind...please give me a hint ;-) Dude... supplicants are typically configured to trust only the exact one certificate that is in the RADIUS Server (CN=... is in the supplicant conf). If you change the Subject in the cert... the supplicant won't like it any more. Stefan OK, once again; i have cloned a radius-server vm, the new radius-server has a new DNS-Entry, IP and a new certificate. The wlan-ssid is different from that one wich is used by the original radius. I checked both certificates, they match the requirements given by microsoft. The certificates are both singed by same CA, with same O,OU, hash-algorithm, key strength... CN is logically different and is set to host and dns name (are the same) from the new radius, like: CN=new-radius.mydomain.mycountry The complete certification path is installed on the client. The client don't have an extra client certificate, server certificate check is turned off in wireless settings. A cisco wireless controller is used for both SSIDs. Original radius works fine, with both SSIDs, new radius does not. So what's wrong? Juergen - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: PEAP/MSCHAPv2 problem
Hi, The complete certification path is installed on the client. The client don't have an extra client certificate, server certificate check is turned off in wireless settings. Turned off? Thanks, that's a new piece of info! That would hint towards a different problem indeed. Original radius works fine, with both SSIDs, new radius does not. So what's wrong? The debug output still points towards: the client doesn't want to speak to the server after starting the EAP conversation. If it's not a certificate problem, something else is different between the two RADIUS servers. What did you do after cloning the VM? Did you upgrade FreeRADIUS from an older version maybe? It would certainly help if you could post the debug output of the old server vs. the new one; for the EAP conversation in its entirety, not just the last packet exchange. If you positively want to rule out that the certificate change was the problem, you could, if your CA's policy allows, install the old server's certificate on the new instance. For IEEE 802.1X, there is no requirement that DNS names and CN/subjectAltNames match. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: PEAP/MSCHAPv2 problem
Jürgen Stader wrote: OK, once again; i have cloned a radius-server vm, the new radius-server has a new DNS-Entry, IP and a new certificate. Well, that's likely the problem. Have you tried using the *working* certificate in the new machine? The wlan-ssid is different from that one wich is used by the original radius. I see. You've changed a number of things at the same time, and are trying to understand why it isn't working. That isn't good practice. I checked both certificates, they match the requirements given by microsoft. The certificates are both singed by same CA, with same O,OU, hash-algorithm, key strength... CN is logically different and is set to host and dns name (are the same) from the new radius, like: CN=new-radius.mydomain.mycountry The certificates are checked before the supplicant is on the network. Hostname and DNS names are irrelevant. The complete certification path is installed on the client. The client don't have an extra client certificate, server certificate check is turned off in wireless settings. A cisco wireless controller is used for both SSIDs. Original radius works fine, with both SSIDs, new radius does not. So what's wrong? The debug log points you a page on the Wiki. The Wiki contains complete instructions for debugging it both on the server side, and on the supplicant side. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: PEAP/MSCHAPv2 problem
Hello,
rad_recv: Access-Request packet from host ... port 32769, id=219,
length=159
User-Name = xy
[...]
EAP-Message = 0x0202000b01737461646572
It would also help not to mangle the debug output by hand, if that's
what happened here. The EAP-Message's EAP-Response/Identity says the
username is stader, while the RADIUS User-Name attribute says xy?
If that is *really* what came in over the wire, your Controller is doing
dumb things. If it was manual editing, please stop doing that, it really
doesn't help us helping you. Or mangle the EAP-Response/Identity to be
consistent with your other edit, at least :-)
Greetings,
Stefan Winter
Message-Authenticator = 0xe5b0ffbed84243bf27ac1ac9c9fcd0b5
server eduroam {
# Executing section authorize from file
/etc/freeradius/sites-enabled/eduroam
+- entering group authorize {...}
[suffix] No '@' in User-Name = xy, looking up realm NULL
[suffix] Found realm NULL
[suffix] Adding Realm = NULL
[suffix] Authentication realm is LOCAL.
++[suffix] returns ok
++[mschap] returns noop
[eap] EAP packet type response id 2 length 11
[eap] No EAP Start, assuming it's an on-going EAP conversation
++[eap] returns updated
Found Auth-Type = EAP
# Executing group from file /etc/freeradius/sites-enabled/eduroam
+- entering group authenticate {...}
[eap] EAP Identity
[eap] processing type tls
[tls] Initiate
[tls] Start returned 1
++[eap] returns handled
} # server eduroam
Sending Access-Challenge of id 219 to ... port 32769
EAP-Message = 0x010300061920
Message-Authenticator = 0x
State = 0x3abc7e1c3abf6764392496688aff7b3f
Finished request 0.
Going to the next request
Waking up in 4.9 seconds.
rad_recv: Access-Request packet from host ... port 32769, id=219,
length=159
Sending duplicate reply to client WLC-TUT port 32769 - ID: 219
Sending Access-Challenge of id 219 to ... port 32769
Waking up in 2.0 seconds.
Cleaning up request 0 ID 219 with timestamp +3
WARNING:
!!
WARNING: !! EAP session for state 0x3abc7e1c3abf6764 did not finish!
WARNING: !! Please read
http://wiki.freeradius.org/Certificate_Compatibility
WARNING:
!!
Ready to process requests.
eap.conf:
eap {
default_eap_type = peap
timer_expire = 60
ignore_unknown_eap_types = no
cisco_accounting_username_bug = no
md5 {
}
tls {
certdir= /etc/hostcertkey
cadir = /etc/cacert
dh_file = ${certdir}/dh
private_key_file = ${certdir}/roaming.key
certificate_file = ${certdir}/roaming.pem
CA_file = ${cadir}/chain.txt
dh_file = ${certdir}/dh
random_file = /dev/urandom
fragment_size = 1024
include_length = yes
check_crl = no
cipher_list = DEFAULT
}
ttls {
default_eap_type = mschapv2
copy_request_to_tunnel = yes
#use_tunneled_reply = yes
virtual_server = eduroam-inner-tunnel
}
peap {
default_eap_type = mschapv2
copy_request_to_tunnel = yes
#use_tunneled_reply = yes
#proxy_tunneled_request_as_eap = yes
virtual_server = eduroam-inner-tunnel
}
mschapv2 {
}
}
--
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la
Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
Tel: +352 424409 1
Fax: +352 422473
signature.asc
Description: OpenPGP digital signature
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: PEAP/MSCHAPv2 problem
Hi, No, the machines are indetical, only changed IP, hostname and certificates. No updates or something. Okay... I put the debug output in appendix. Sorry i had to remove passwords and IPs because of security reasons, i think you will understand ;-) That part of mangling is okay :-) If you positively want to rule out that the certificate change was the problem, you could, if your CA's policy allows, install the old server's certificate on the new instance. For IEEE 802.1X, there is no requirement that DNS names and CN/subjectAltNames match. This was the first thing i tried... Good! Looking at the output, things become clearer. The conversation ends when the server tries to send the first Access-Challenge packet to the client. It seems like that packet never gets there - and so the client retransmits the same Request over and over again. The server then repeatedly tries to re-send its reply, but again, it never seems to get there. Make sure that the changed IP address doesn't lead to some firewall (host FW? net FW? Cisco Controller's ACLs?) eats the responses. At least it is now apparent that it's not a certificate issue - the EAP conversation doesn't even get far enough to send certificate data at all. In any case, I don't think the FreeRADIUS server process is to be blamed - it sends a well-formed response to a reasonable request. Something's wrong between the server OS and the supplicant. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: PEAP/MSCHAPv2 problem
Hi,
PEAP can work with or without client certs. Both run through the tls
instance; that is no error. The problem is much rather here:
Sending Access-Challenge of id 219 to ... port 32769
Waking up in 2.0 seconds.
Cleaning up request 0 ID 219 with timestamp +3
WARNING:
!!
WARNING: !! EAP session for state 0x3abc7e1c3abf6764 did not finish!
WARNING: !! Please read
http://wiki.freeradius.org/Certificate_Compatibility
WARNING:
!!
Ready to process requests.
The client probably doesn't like the server certificate, and stops
talking to the server.
When you cloned your RADIUS server, did you give the clone a different
certificate afterwards? FreeRADIUS will generate a sample one on first
start. If your client only trusts the old one, it won't talk to the new
one...
Greetings,
Stefan Winter
eap.conf:
eap {
default_eap_type = peap
timer_expire = 60
ignore_unknown_eap_types = no
cisco_accounting_username_bug = no
md5 {
}
tls {
certdir= /etc/hostcertkey
cadir = /etc/cacert
dh_file = ${certdir}/dh
private_key_file = ${certdir}/roaming.key
certificate_file = ${certdir}/roaming.pem
CA_file = ${cadir}/chain.txt
dh_file = ${certdir}/dh
random_file = /dev/urandom
fragment_size = 1024
include_length = yes
check_crl = no
cipher_list = DEFAULT
}
ttls {
default_eap_type = mschapv2
copy_request_to_tunnel = yes
#use_tunneled_reply = yes
virtual_server = eduroam-inner-tunnel
}
peap {
default_eap_type = mschapv2
copy_request_to_tunnel = yes
#use_tunneled_reply = yes
#proxy_tunneled_request_as_eap = yes
virtual_server = eduroam-inner-tunnel
}
mschapv2 {
}
}
--
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la
Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
Tel: +352 424409 1
Fax: +352 422473
signature.asc
Description: OpenPGP digital signature
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: PEAP/MSCHAPv2 problem
Hi,
thanks for your reply.
Am 04.04.2011 16:27, schrieb Stefan Winter:
Hi,
PEAP can work with or without client certs. Both run through the tls
instance; that is no error. The problem is much rather here:
Sending Access-Challenge of id 219 to ... port 32769
Waking up in 2.0 seconds.
Cleaning up request 0 ID 219 with timestamp +3
WARNING:
!!
WARNING: !! EAP session for state 0x3abc7e1c3abf6764 did not finish!
WARNING: !! Please read
http://wiki.freeradius.org/Certificate_Compatibility
WARNING:
!!
Ready to process requests.
The client probably doesn't like the server certificate, and stops
talking to the server.
When you cloned your RADIUS server, did you give the clone a different
certificate afterwards? FreeRADIUS will generate a sample one on first
start. If your client only trusts the old one, it won't talk to the new
one...
The original radius has a trusted certificate, signed by our CA. The
clone has also a trusted certificate with its DN registred in DNS.
I edited the corresponding section in eap.conf and placed the filename
of the new certificate- and keyfile.
private_key_file = ${certdir}/roaming.key
certificate_file = ${certdir}/roaming.pem
The certificates were generate with the same attributes (exept the DN).
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: PEAP/MSCHAPv2 problem
Jürgen Stader wrote:
When you cloned your RADIUS server, did you give the clone a different
certificate afterwards?
Since you didn't answer that question directly, it looks like a yes.
The original radius has a trusted certificate, signed by our CA. The
clone has also a trusted certificate with its DN registred in DNS.
I edited the corresponding section in eap.conf and placed the filename
of the new certificate- and keyfile.
private_key_file = ${certdir}/roaming.key
certificate_file = ${certdir}/roaming.pem
The certificates were generate with the same attributes (exept the DN).
Which avoids answering the question.
The solution to the problem is simple. The answer is in front of you.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: PEAP/MSCHAPv2 problem
Am 04.04.2011 18:02, schrieb Alan DeKok:
Jürgen Stader wrote:
When you cloned your RADIUS server, did you give the clone a different
certificate afterwards?
Since you didn't answer that question directly, it looks like a yes.
You' re right, but you can read this out of the lines. The two machines
have different certificates. Signed from same CA.
The original radius has a trusted certificate, signed by our CA. The
clone has also a trusted certificate with its DN registred in DNS.
I edited the corresponding section in eap.conf and placed the filename
of the new certificate- and keyfile.
private_key_file = ${certdir}/roaming.key
certificate_file = ${certdir}/roaming.pem
The certificates were generate with the same attributes (exept the DN).
Which avoids answering the question.
The solution to the problem is simple. The answer is in front of you.
Alan DeKok.
Looks like i'm blind...please give me a hint ;-)
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: PEAP/MSCHAPv2 problem
Hi, The solution to the problem is simple. The answer is in front of you. Alan DeKok. Looks like i'm blind...please give me a hint ;-) Dude... supplicants are typically configured to trust only the exact one certificate that is in the RADIUS Server (CN=... is in the supplicant conf). If you change the Subject in the cert... the supplicant won't like it any more. Stefan -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
