multiotp with strongswan has no (ms)-chap-challenge

[Phil Frost]

On Fri, Mar 16, 2018 at 2:52 PM Alan DeKok <aland at 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.