On Mar 16, 2018, at 3:18 PM, Phil Frost <phil@postmates.com> wrote:
Thanks, this has been extremely helpful. So my issues came down to two things:
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.
No. That's not how RADIUS works. The *only* way that FreeRADIUS knows a system can do EAP is that the system sends a RADIUS packet containing EAP-Messge.
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.
Yes. That's how RADIUS works. As a hint, if there's no way to configure something, it's probably because that thing is impossible, or wrong.
2. I was missing "eap" in my authorize{} section in the freeradius config.
The default configuration contains "eap" among many other things for a reason...
Once I got strongswan sending the initial EAP-Message this was obvious from the freeradius debug output.
That's good to hear. Alan DeKok.