Hi, after some thorough investigation, I'm reasonably sure that it's not strongswan's fault, but the IKEv2 VPN client on WIndows 7.
The thing is: if you "Enable Identity privacy" for PEAP and set it to some string, - the outer identity is the IP address (NOT the string you entered) - the inner identity is the true user identity But if you disable Identity Privacy, - the outer identity is the IP address - ** there is no inner auth, because the tunnel content is malformed ** So there is definitely some supplicant misbehaviour (the inner tunnel is definitely not in strongswan's manipulation range). When decoding the tunnel, this manifests as follows: - with ID privacy, after finishing the TLS tunnel setup: [peap] Done initial handshake [peap] eaptls_process returned 7 [peap] EAPTLS_OK [peap] Session established. Decoding tunneled attributes. [peap] Identity - claude.tomp...@education.lu [peap] Got tunneled request - without ID privacy: [peap] Done initial handshake [peap] eaptls_process returned 7 [peap] EAPTLS_OK [peap] Session established. Decoding tunneled attributes. [peap] Tunneled data is invalid. [eap] Handler failed in EAP/peap [eap] Failed in EAP select ++[eap] returns invalid Failed to authenticate the user. Huh? Stefan Am 08.04.2010 16:47, schrieb Alan DeKok: > Stefan Winter wrote: > >> Ah, I found something about that. strongswan forwards the EAP message in >> RADIUS, and both of EAP-Resp/Identity and consequently User-Name are set >> to the *IP address* of the connecting client (the non-tunnel one). >> This looks like >> >> rad_recv: Access-Request packet from host 158.64.1.13 port 33044, >> id=199, length=97 >> User-Name = " \001\n\030\000\000\004\003aW\025����\353" >> EAP-Message = 0x020000150120010a1800000403615715fda1b3aeeb >> >> when the client's public IP address is 2001:0a18:0000:0403:... >> > That is an absolutely horrible thing to do. They should fix that ASAP. > > >> We're still tryinto stop that from happening. Either it's windows >> which thinks it has to identify itself with its IP address (even though >> we're PEAPing here, and "Enable identity privacy" is set - so it is >> explicitly told to use that string to authenticate), or it's strongswan >> making this up by itself. >> >> Anyway, not a FreeRADIUS problem. >> > I've had conversations with the Strongswan people, and met them in > person. So if you have issues, CC me in email... > > Alan DeKok. > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- 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
