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 :-)