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.tompers@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