Phil Frost <phil@postmates.com> wrote:
1. In strongswan.conf, I had "charon.eap-radius.eap_start = yes". This needs to be "no". This is why there was no EAP-Message in the initial exchange with freeradius. I found this confusingly backwards -- "eap_start = no" means strongswan SHOULD start the EAP exchange. If it's set to "yes" then it just sends an Access-Request to freeradius with no EAP-Message, and freeradius is supposed to reply with an EAP-Message. As far as I've seen there's no way to configure freeradius this way: an Access-Request which contains to EAP-Message nor any other kind of credentials will simply be rejected with Access-Reject, which tells stronsgwan to fail the IKEv2 exchange.
Either that option is broken due to bitrot, or there is some use case in sending an EAP-Start *to* the client (not that I know of). AFAICT the idea here would be to send it to FR, and it obviously does not. rlm_eap does document that it will detect an EAP-Start and send back an identity, though normally it is the NAS that should handle this part of the exchange. At any rate there's a comment saying not to use the option with FR in the default strongswan config file: # Send EAP-Start instead of EAP-Identity to start RADIUS conversation. # Doing this gives FreeRADIUS fits... some sort of hardcoded forwarding loop # eap_start = yes ...I'm not sure if the alleged "loop" problem is still a problem