Thanks Phil and Alan for your inputs. I got it working by, *not* following https://wiki.freeradius.org/guide/multiOTP-HOWTO instead in the file */etc/raddb/mods-enabled/mschap* *mschap {* * ntlm_auth = "/usr/bin/multiotp %{User-Name} %{User-Password} -request-nt-key -src=%{Packet-Src-IP-Address} -chap-challenge=%{CHAP-Challenge} -chap-password=%{CHAP-Password} -ms-chap-challenge=%{MS-CHAP-Challenge} -ms-chap-response=%{MS-CHAP-Response} -ms-chap2-response=%{MS-CHAP2-Response}"* * .....* *}* My guess/theory is this https://wiki.freeradius.org/guide/multiOTP-HOWTO says to update the policy and *Auth-Type == multiotp/**multiotpmschap *which will never run mschap during authenticate output with NO multiotp configured.. I found somewhere mschap plugin is creating the variable MS-CHAP-Challenge (may be from EAP-Message) *(13) mschap: Creating challenge hash with username: karthik* *(13) mschap: Client is using MS-CHAPv2* *(13) mschap: Adding MS-CHAPv2 MPPE keys* but it finally there is MS-CHAP-Challenge *(6) eap_mschapv2: # Executing group from file /etc/raddb/sites-enabled/default* *(6) eap_mschapv2: authenticate {* *(6) mschap: Creating challenge hash with username: kumar* *(6) mschap: Client is using MS-CHAPv2* *(6) mschap: Executing: /usr/bin/multiotp %{User-Name} %{User-Password} -request-nt-key -src=%{Packet-Src-IP-Address} -chap-challenge=%{CHAP-Challenge} -chap-password=%{CHAP-Password} -ms-chap-challenge=%{MS-CHAP-Challenge} -ms-chap-response=%{MS-CHAP-Response} -ms-chap2-response=%{MS-CHAP2-Response}:* *(6) mschap: EXPAND %{User-Name}* *(6) mschap: --> kumar* *(6) mschap: EXPAND %{User-Password}* *(6) mschap: -->* *(6) mschap: EXPAND -src=%{Packet-Src-IP-Address}* *(6) mschap: --> -src=127.0.0.1* *(6) mschap: EXPAND -chap-challenge=%{CHAP-Challenge}* *(6) mschap: --> -chap-challenge=* *(6) mschap: EXPAND -chap-password=%{CHAP-Password}* *(6) mschap: --> -chap-password=* *(6) mschap: EXPAND -ms-chap-challenge=%{MS-CHAP-Challenge}* *(6) mschap: --> -ms-chap-challenge=0xba877ea85ac1d74ab0daa496b4cfb55c* *(6) mschap: EXPAND -ms-chap-response=%{MS-CHAP-Response}* *(6) mschap: --> -ms-chap-response=* *(6) mschap: EXPAND -ms-chap2-response=%{MS-CHAP2-Response}* *(6) mschap: --> -ms-chap2-response=0x02758b70955a1e940db1a14e946ca53eaaf000000000000000007f1121d3a2f97727df83b1cb92e150b69b95f0d6b28c6138* thanks On Fri, Mar 16, 2018 at 10:03 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Mar 16, 2018, at 3:51 PM, Phil Frost <phil@postmates.com> wrote:
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.
Sometimes it's useful to re-iterate the steps to the end goal.
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,
RADIUS always contains attribute-value pairs...
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.
Sort of... CHAP-Challenge *is* a RADIUS attribute, which you do see in RADIUS packets.
In your case, you're using EAP-MSCHAPv2. Which ends up being transported over RADIUS, which contains EAP-Message, which on turn contains EAP, which contains sub-type EP-MSCHAPv2, which then contains the MS-CHAPv2 data.
It's all a bit miraculous that it works...
So if radtest works, but things fail when you try through strongswan, it may be that EAP is not working.
That's why there are comments at the top of the "inner-tunnel" virtual server.
And that's why the debug output is so voluminous and detailed.
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.
That's a bad thing to do to users... it should NOT be possible to configure Strongswan to violate the RFCs in this way.
Alan Dekok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html