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
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
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
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
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
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
6 matches
Mail list logo
