Phil Frost <phil@postmates.com> wrote
When strongswan is configured to use the eap-radius plugin, there is no additional configuration for strongswan to indicate what EAP method should be used. Please excuse my ignorance as I'm still learning these things, but isn't the EAP protocol initiated by the authenticator, in this case strongswan, and by proxy, freeradius?
I think you meant to reply on the other thread, so I changed the subject back. That's the way it normally happens, but I believe there are mechanisms to have the AAA server send the EAP Identity-request instead. There are no EAP type options in strongswan because negotiating that (to the extent the protocol allows it) is between the AAA server and client. The NAS may send the EAP-Identity request and handles crowbarring EAP messages into whatever it is using to communicate to the client, but otherwise is just a go between for the EAP conversation. However I did just look at some old logs I had kicking around and you should be getting an EAP-Message attribute on your first packet received on the FreeRADIUS side. So maybe your session is falling into a connection profile not set to auth: eap-radius? In any case as long as you are using eap-radius you'll need to configure the eap module and ensure it is activated in the relevant sections. You configure the mschapv2 or inner-eap-then-mschapv2 exchange in that module's config section. On the client side I don't know if the "smart" autodetection features on clients work... I've always configured them to know what EAP type to expect because you have to do that to lock down the PKI securely, anyway. As to strongswan not sending the initial EAP-Message attribute that's something to look at strongswan logs for and maybe ask on #strongswan.