Strongswan integration, Access-Request contains no credentials?
I'm attempting to configure an IKEv2 VPN which uses strongswan's eap-radius plugin to delegate authentication to freeradius. I've configured freeradius to authenticate against Active Directory by executing ntlm_auth, and I'm hoping to use mschapv2 authentication. I'm able to successfully authenticate with radtest: radtest -x -t mschap phil.frost redacted 127.0.0.1 0 redacted Sending Access-Request of id 193 to 127.0.0.1 port 1812 User-Name = "phil.frost" NAS-IP-Address = 127.0.0.1 NAS-Port = 0 Message-Authenticator = 0x00000000000000000000000000000000 MS-CHAP-Challenge = redacted MS-CHAP-Response = redacted rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=193, length=84 MS-CHAP-MPPE-Keys = redacted MS-MPPE-Encryption-Policy = redacted MS-MPPE-Encryption-Types = redacted I'm also able to connect to the VPN if I use the eap-mschapv2 strongswan plugin in lieu of eap-radius and configure a plaintext password in strongswan's user database. So it would appear the issue is the integration between the two. Should strongswan be including the credentials? Or should freeradius be doing something to indicate the VPN client should present them? I've learned many ways things could work, but a hint at how they *should* work in this case would very much help me narrow what's otherwise been a fruitless search through a combinatorial explosion of RFCs and protocol options. This seems to be the most salient part of the freeradius output. The unabbridged debug output is attached. rad_recv: Access-Request packet from host 127.0.0.1 port 60479, id=236, length=137 User-Name = "phil.frost" NAS-Port-Type = Virtual Service-Type = Framed-User NAS-Port = 5 NAS-Port-Id = "ikev2-vpn" NAS-IP-Address = 10.6.0.81 Called-Station-Id = "10.6.0.81[4500]" Calling-Station-Id = "73.161.191.57[4500]" NAS-Identifier = "strongSwan" Message-Authenticator = redacted # Executing section authorize from file /etc/freeradius/sites-enabled/postmates +group authorize { ++[preprocess] = ok ++[mschap] = noop +} # group authorize = ok ERROR: No authenticate method (Auth-Type) found for the request: Rejecting the user Failed to authenticate the user.
Phil Frost <phil@postmates.com> wrote:
So it would appear the issue is the integration between the two. Should strongswan be including the credentials? Or should freeradius be doing something to indicate the VPN client should present them? I've learned many ways things could work, but a hint at how they *should* work in this case would very much help me narrow what's otherwise been a fruitless search through a combinatorial explosion of RFCs and protocol options.
The eap-radius strongswan plugin should talk EAP to FreeRADIUS, so you should be setting up the eap module with mschap as eap method, (or for Windows Agile, PEAP with eap-mschapv2 as the inner method if you want to make sure Windows clients won't trust a doppleganger MiTM because Windows does not properly validate PKI things when using just eap-mschapv2.) You seem to be configured for straight mschapv2. Fix that first. Note that there is no EAP-Message in the request. Strongswan doesn't send an EAP-Start without configuring it to, but says not to do so with FreeRADIUS anyway. I think it just kicks into gear when FR sends an EAP Identity-Request and then you should see EAP messages in the second packet from the strongswan NAS. Then the mschap session will appear inside EAP. I have both EAP-MSCHAPv2 (for OSX and strongswan clients) and EAP-PEAP-MSCHAPv2 (for Windows) working with a FR AAA backend, so rest assured it is possible :-)
participants (2)
-
Brian Julin -
Phil Frost