On Fri, Mar 16, 2018 at 2:52 PM Alan DeKok <aland@deployingradius.com> wrote:
When I say *No amount of poking FreeRADIUS will magically create that attribute Only Strongswan can do that.*... I really mean it. Please don't respond with "but how do I configure FreeRADIUS..." I already told you that you need to configure the *client*.
Thank you for this eloquent statement of the obvious. Karthik, having very recently grappled with my own strongswan and freeradius integration, I'll offer a few things that may help. It took a while for these to "click" while I was troubleshooting. Firstly, "straight" RADIUS exchanges attribute-value pairs. Those attribute-value pairs have things like usernames and passwords in them. freeradius checks them, obviously. I believe when you are using radtest, you are exercising this mode of operation. But this is not how freeradius and strongswan work. In the case of IKEv2, authentication in your case happens via EAP. In this mode of operation, IKEv2 and RADIUS are just transports for EAP. EAP-in-RADIUS is described in RFC 3579. It amounts to taking the EAP protocol, and stuffing it inside an EAP-Message attribute. You'll never see the chap challenge in a RADIUS attribute, because it's inside EAP, which is inside the EAP-Message attribute. So if radtest works, but things fail when you try through strongswan, it may be that EAP is not working. I'd suggest starting freeradius as "freeradius -X" or "radiusd -X", and you can then see the RADIUS attribute-value pairs as freeradius sees them. You must configure in strongswan's eap-radius plugin the option "eap_start = no". If you do not do this, strongswan will send an Access-Request containing the IKEv2 identity from the initiator, but no credentials and no EAP-Message to freeradius. Strongswan is expecting freeradius to begin the EAP exchange ("magically", as Alan puts it) and respond with an Access-Challenge containing an EAP-Message, but freeradius can not be configured this way as far as I've seen. You must set "eap_start = no" to tell strongswan it should be the one starting the EAP exchange (yes, it's "backwards"). You can confirm this is working correctly by watching the debug output of freeradius and verifying that in the first Access-Request it receives from strongswan there exists an EAP-Message attribute. If there is no EAP-Message attribute, freeradius will reject the request because it contains no credentials and the VPN connection will fail.
From there your difficulties may lie in having your authentication working for straight RADIUS, but not EAP. I've not configured multiotp specifically, but from that tutorial it sounds like it works as MSCHAPv2 but the password happens to be an OTP. Read the debug output carefully, and remember that you need to be configuring the eap module as well as the mschap module. You should see freeradius determine that Auth-Type is EAP, and then see eap hand off to the mschap module.