Win 7 IKEv2+PEAP = "no NPS server"?
Hello, I wonder if anyone else has come across this already... Google is not very helpful here. We're setting up a VPN Server (strongswan) with Windows 7 in IKEv2 mode. The client side is supposed to authenticate with PEAP(*) to FreeRADIUS. That works pretty well, but on the first PEAP connection to the server, there's a big fat warning on the Win 7 UI: "You're connecting to a server which is not a valid NPS Server for this domain. You are strongly discouraged from continuing... bla..." If you click Connect, *everything works*. Now I'm wondering what needs to be done to make that useless warning go away... Maybe the FreeRADIUS server certificate needs yet another Extended Key Usage or so? I didn't really find helpful documentation. I wonder why it's Win 7's business anyway: of course the other end is not a NPS server. It's FreeRADIUS. But why would an EAP client consider it its own business to warn about a vendor discrepancy on the RADIUS far end? Greetings, Stefan Winter (*) If you just select EAP-MSCHAPv2 (no inner tunnel), the end result at the FR side is a crippled User-Name (which makes it impossible to auth users). Whether it's Win 7 or the strongswan EAP -> RADIUS conversion that gets it wrong, I don't know. -- 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
On 08/04/10 14:27, Stefan Winter wrote:
Hello,
I wonder if anyone else has come across this already... Google is not very helpful here.
We're setting up a VPN Server (strongswan) with Windows 7 in IKEv2 mode. The client side is supposed to authenticate with PEAP(*) to FreeRADIUS. That works pretty well, but on the first PEAP connection to the server, there's a big fat warning on the Win 7 UI: "You're connecting to a server which is not a valid NPS Server for this domain. You are strongly discouraged from continuing... bla..." If you click Connect, *everything works*. Now I'm wondering what needs to be done to make that useless warning go away... Maybe the FreeRADIUS server certificate needs yet another Extended Key Usage or so? I didn't really find helpful documentation.
Interesting. I coded up PEAP/SoH support a while back, and IIRC Alan is dragging it into the 2.2 version. If you're curious you could try the code here: git clone git@git.freeradius.org:soh.git peap-soh git checkout -b peap-soh origin/peap-soh ...see "eap.conf" for brief docs. I presume the warning will go away...
Stefan Winter wrote:
We're setting up a VPN Server (strongswan) with Windows 7 in IKEv2 mode. The client side is supposed to authenticate with PEAP(*) to FreeRADIUS. That works pretty well, but on the first PEAP connection to the server, there's a big fat warning on the Win 7 UI: "You're connecting to a server which is not a valid NPS Server for this domain. You are strongly discouraged from continuing... bla..."
Go through the Windows GUI, and look for "health checks", or something like that... turn those off.
(*) If you just select EAP-MSCHAPv2 (no inner tunnel), the end result at the FR side is a crippled User-Name (which makes it impossible to auth users).
Hmm... what does that mean? Alan DeKok.
Hi,
Go through the Windows GUI, and look for "health checks", or something like that... turn those off.
I suspected that as well, but NAP stuff is off. But now that I deleted and re-created the VPN setup, it doesn't ask me again. Probably it remembered my decision to "connect anyway" eternally. Grr.
(*) If you just select EAP-MSCHAPv2 (no inner tunnel), the end result at the FR side is a crippled User-Name (which makes it impossible to auth users).
Hmm... what does that mean?
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:... We're still trying to 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. 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
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.
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
Stefan Winter wrote:
[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?
Run the server with '-Xx' to get a hex dump of the tunneled data. That will give a bit more information about what's going on. Alan DeKok.
Hi,
Run the server with '-Xx' to get a hex dump of the tunneled data. That will give a bit more information about what's going on.
that doesn't reveal much new info. For outer id set, it dumps the inner EAP-Message, but for unset, only the error message. -Xxxx (-Xx looks the same): - with id privacy Mon Apr 12 08:08:25 2010 : Info: +- entering group authenticate {...} Mon Apr 12 08:08:25 2010 : Info: [eap] Request found, released from the list Mon Apr 12 08:08:25 2010 : Info: [eap] EAP/peap Mon Apr 12 08:08:25 2010 : Info: [eap] processing type peap Mon Apr 12 08:08:25 2010 : Info: [peap] processing EAP-TLS Mon Apr 12 08:08:25 2010 : Info: [peap] eaptls_verify returned 7 Mon Apr 12 08:08:25 2010 : Info: [peap] Done initial handshake Mon Apr 12 08:08:25 2010 : Info: [peap] eaptls_process returned 7 Mon Apr 12 08:08:25 2010 : Info: [peap] EAPTLS_OK Mon Apr 12 08:08:25 2010 : Info: [peap] Session established. Decoding tunneled attributes. Mon Apr 12 08:08:25 2010 : Info: [peap] Identity - claude.tompers@education.lu Mon Apr 12 08:08:25 2010 : Info: [peap] Got tunneled request EAP-Message = 0x0205002001636c617564652e746f6d7065727340656475636174696f6e2e6c75 server VPN { Mon Apr 12 08:08:25 2010 : Debug: PEAP: Got tunneled identity of claude.tompers@education.lu Mon Apr 12 08:08:25 2010 : Debug: PEAP: Setting default EAP type for tunneled EAP session. Mon Apr 12 08:08:25 2010 : Debug: PEAP: Setting User-Name to claude.tompers@education.lu Sending tunneled request EAP-Message = 0x0205002001636c617564652e746f6d7065727340656475636174696f6e2e6c75 FreeRADIUS-Proxied-To = 127.0.0.1 User-Name = "claude.tompers@education.lu" NAS-Port-Type = Virtual NAS-Identifier = "strongSwan" RESTENA-Service-Type = "VPN" - without id privacy: Mon Apr 12 08:07:38 2010 : Info: +- entering group authenticate {...} Mon Apr 12 08:07:38 2010 : Info: [eap] Request found, released from the list Mon Apr 12 08:07:38 2010 : Info: [eap] EAP/peap Mon Apr 12 08:07:38 2010 : Info: [eap] processing type peap Mon Apr 12 08:07:38 2010 : Info: [peap] processing EAP-TLS Mon Apr 12 08:07:38 2010 : Info: [peap] eaptls_verify returned 7 Mon Apr 12 08:07:38 2010 : Info: [peap] Done initial handshake Mon Apr 12 08:07:38 2010 : Info: [peap] eaptls_process returned 7 Mon Apr 12 08:07:38 2010 : Info: [peap] EAPTLS_OK Mon Apr 12 08:07:38 2010 : Info: [peap] Session established. Decoding tunneled attributes. Mon Apr 12 08:07:38 2010 : Info: [peap] Tunneled data is invalid. Mon Apr 12 08:07:38 2010 : Info: [eap] Handler failed in EAP/peap Mon Apr 12 08:07:38 2010 : Info: [eap] Failed in EAP select Mon Apr 12 08:07:38 2010 : Info: ++[eap] returns invalid Mon Apr 12 08:07:38 2010 : Info: Failed to authenticate the user. Mon Apr 12 08:07:38 2010 : Auth: Login incorrect: [ \001\n\030\000\000\004\003\235A\2112\236\240\242\220/<via A uth-Type = EAP>] (from client vpn6-test-v4 port 0) 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
Stefan Winter wrote:
that doesn't reveal much new info. For outer id set, it dumps the inner EAP-Message, but for unset, only the error message. -Xxxx (-Xx looks the same):
Hmm... OK. Maybe you need to build a development version. I'll see if I can fix this for 2.1.9, so it prints out the hex by default for bad packets. Alan DeKok.
participants (3)
-
Alan DeKok -
Phil Mayers -
Stefan Winter