multiotp with strongswan has no (ms)-chap-challenge
Hi, I am setting up 2factor auth and we use Strongswan as our VPN server. I use FreeRADIUS as backend of Strongwan. This is the setup mac osx (ikev2 with eap-mschapv2) ---> Strongswan ---> FreeRADIUS --> multiotp First I tried with clear text password in /etc/raddb/users and it is successful. For 2factor I need to pair it with multiOTP. I followed the doc https://wiki.freeradius.org/guide/multiOTP-HOWTO and it is successfully working *# radtest -t mschap kumar `oathtool --totp 3683453456769abc3452` 127.0.0.1 0 testing123* *Sent Access-Request Id 1 from 0.0.0.0:53097 <http://0.0.0.0:53097> to 127.0.0.1:1812 <http://127.0.0.1:1812> length 131* * User-Name = "kumar"* * MS-CHAP-Password = "987897"* * NAS-IP-Address = 127.0.0.1* * NAS-Port = 0* * Message-Authenticator = 0x00* * Cleartext-Password = "987897"* * MS-CHAP-Challenge = 0xcb76ef02a264e636* * MS-CHAP-Response = 0x0001000000000000000000000000000000000000000000000000021c2d6262c11c88b4265e63da64e4f80dc46364e75d90df* *Received Access-Reject Id 1 from 127.0.0.1:1812 <http://127.0.0.1:1812> to 0.0.0.0:0 <http://0.0.0.0:0> length 61* *(0) multiotp: Executing: /usr/bin/multiotp %{User-Name} %{User-Password} -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}:* *(0) multiotp: EXPAND %{User-Name}* *(0) multiotp: --> kumar* *(0) multiotp: EXPAND %{User-Password}* *(0) multiotp: -->* *(0) multiotp: EXPAND -src=%{Packet-Src-IP-Address}* *(0) multiotp: --> -src=127.0.0.1* *(0) multiotp: EXPAND -chap-challenge=%{CHAP-Challenge}* *(0) multiotp: --> -chap-challenge=* *(0) multiotp: EXPAND -chap-password=%{CHAP-Password}* *(0) multiotp: --> -chap-password=* *(0) multiotp: EXPAND -ms-chap-challenge=%{MS-CHAP-Challenge}* *(0) multiotp: --> -ms-chap-challenge=0xcb76ef02a264e636* *(0) multiotp: EXPAND -ms-chap-response=%{MS-CHAP-Response}* *(0) multiotp: --> -ms-chap-response=0x0001000000000000000000000000000000000000000000000000021c2d6262c11c88b4265e63da64e4f80dc46364e75d90df* *(0) multiotp: EXPAND -ms-chap2-response=%{MS-CHAP2-Response}* *(0) multiotp: --> -ms-chap2-response=* *(0) multiotp: Program returned code (0) and output ''* *(0) multiotp: Program executed successfully* *(0) [multiotp] = ok* But when I use Strongswan, there is no MS-CHAP-Challenge (i tried with %{mschap:Challenge}) *(1) multiotp: 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}:* *(1) multiotp: EXPAND %{User-Name}* *(1) multiotp: --> karthik* *(1) multiotp: EXPAND %{User-Password}* *(1) multiotp: -->* *(1) multiotp: EXPAND -src=%{Packet-Src-IP-Address}* *(1) multiotp: --> -src=127.0.0.1* *(1) multiotp: EXPAND -chap-challenge=%{CHAP-Challenge}* *(1) multiotp: --> -chap-challenge=* *(1) multiotp: EXPAND -chap-password=%{CHAP-Password}* *(1) multiotp: --> -chap-password=* *(1) multiotp: EXPAND -ms-chap-challenge=%{MS-CHAP-Challenge}* *(1) multiotp: --> -ms-chap-challenge=* *(1) multiotp: EXPAND -ms-chap-response=%{MS-CHAP-Response}* *(1) multiotp: --> -ms-chap-response=* *(1) multiotp: EXPAND -ms-chap2-response=%{MS-CHAP2-Response}* *(1) multiotp: --> -ms-chap2-response=* Any help on this please ? Thanks
On Mar 16, 2018, at 5:10 AM, karthik kumar <kumarkarthikn@gmail.com> wrote:
I am setting up 2factor auth and we use Strongswan as our VPN server. I use FreeRADIUS as backend of Strongwan.
This is the setup mac osx (ikev2 with eap-mschapv2) ---> Strongswan ---> FreeRADIUS --> multiotp
First I tried with clear text password in /etc/raddb/users and it is successful. For 2factor I need to pair it with multiOTP. I followed the doc https://wiki.freeradius.org/guide/multiOTP-HOWTO ... But when I use Strongswan, there is no MS-CHAP-Challenge (i tried with %{mschap:Challenge})
Then fix Strongswan so that it sends the MS-CHAP-Challenge. No amount of poking FreeRADIUS will magically create that attribute. Only Strongswan can do that. Alan DeKok.
When strongswan is configured to use the eap-radius plugin, there is no additional configuration for strongswan to indicate what EAP method should be used. Please excuse my ignorance as I'm still learning these things, but isn't the EAP protocol initiated by the authenticator, in this case strongswan, and by proxy, freeradius?
From RFC 5996 (IKEv2), section 2.16:
An initiator indicates a desire to use EAP by leaving out the AUTH payload from the first message in the IKE_AUTH exchange. (Note that the AUTH payload is required for non-EAP authentication, and is thus not marked as optional in the rest of this document.) By including an IDi payload but not an AUTH payload, the initiator has declared an identity but has not proven it. If the responder is willing to use an EAP method, it will place an Extensible Authentication Protocol (EAP) payload in the response of the IKE_AUTH exchange and defer sending SAr2, TSi, and TSr until initiator authentication is complete in a subsequent IKE_AUTH exchange.
From what I can gather from the logs and packet captures, at this point strongswan sends an Access-Request to freeradius containing the identity but no credentials (because they don't yet exist). It's reasonable to then wonder if it's now the responsibility of freeradius to initiate the EAP exchange and request the peer to provide the necessary credentials.
Is this not the case? Again please excuse the ignorance -- between IKEv2, RADIUS, EAP, all the various EAP methods, strongswan, freeradius, and each their myriad plugins, it's quite difficult to even understand how these protocols should be working together. Even just a quick example of a working integration between strongswan and freeradius from someone who has done it before would be very valuable. On Fri, Mar 16, 2018 at 9:29 AM Alan DeKok <aland@deployingradius.com> wrote:
On Mar 16, 2018, at 5:10 AM, karthik kumar <kumarkarthikn@gmail.com> wrote:
I am setting up 2factor auth and we use Strongswan as our VPN server. I use FreeRADIUS as backend of Strongwan.
This is the setup mac osx (ikev2 with eap-mschapv2) ---> Strongswan ---> FreeRADIUS --> multiotp
First I tried with clear text password in /etc/raddb/users and it is successful. For 2factor I need to pair it with multiOTP. I followed the doc https://wiki.freeradius.org/guide/multiOTP-HOWTO ... But when I use Strongswan, there is no MS-CHAP-Challenge (i tried with %{mschap:Challenge})
Then fix Strongswan so that it sends the MS-CHAP-Challenge.
No amount of poking FreeRADIUS will magically create that attribute. Only Strongswan can do that.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Phil Frost <phil@postmates.com> wrote
When strongswan is configured to use the eap-radius plugin, there is no additional configuration for strongswan to indicate what EAP method should be used. Please excuse my ignorance as I'm still learning these things, but isn't the EAP protocol initiated by the authenticator, in this case strongswan, and by proxy, freeradius?
I think you meant to reply on the other thread, so I changed the subject back. That's the way it normally happens, but I believe there are mechanisms to have the AAA server send the EAP Identity-request instead. There are no EAP type options in strongswan because negotiating that (to the extent the protocol allows it) is between the AAA server and client. The NAS may send the EAP-Identity request and handles crowbarring EAP messages into whatever it is using to communicate to the client, but otherwise is just a go between for the EAP conversation. However I did just look at some old logs I had kicking around and you should be getting an EAP-Message attribute on your first packet received on the FreeRADIUS side. So maybe your session is falling into a connection profile not set to auth: eap-radius? In any case as long as you are using eap-radius you'll need to configure the eap module and ensure it is activated in the relevant sections. You configure the mschapv2 or inner-eap-then-mschapv2 exchange in that module's config section. On the client side I don't know if the "smart" autodetection features on clients work... I've always configured them to know what EAP type to expect because you have to do that to lock down the PKI securely, anyway. As to strongswan not sending the initial EAP-Message attribute that's something to look at strongswan logs for and maybe ask on #strongswan.
On Fri, Mar 16, 2018 at 2:41 PM Brian Julin <BJulin@clarku.edu> wrote:
However I did just look at some old logs I had kicking around and you should be getting an EAP-Message attribute on your first packet received on the FreeRADIUS side. So maybe your session is falling into a connection profile not set to auth: eap-radius? In any case as long as you are using eap-radius you'll need to configure the eap module and ensure it is activated in the relevant sections. You configure the mschapv2 or inner-eap-then-mschapv2 exchange in that module's config section.
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. 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. 2. I was missing "eap" in my authorize{} section in the freeradius config. Once I got strongswan sending the initial EAP-Message this was obvious from the freeradius debug output. For posterity I'll share what I see in a working setup of a strongswan IKEv2 VPN, with an OS X client performing EAP-MSCHAPv2 authentication. The initial contact from strongswan: rad_recv: Access-Request packet from host 127.0.0.1 port 32872, id=41, length=152 User-Name = "phil.frost" NAS-Port-Type = Virtual Service-Type = Framed-User NAS-Port = 7 NAS-Port-Id = "ikev2-vpn" NAS-IP-Address = ... Called-Station-Id = "..." Calling-Station-Id = "..." EAP-Message = ... NAS-Identifier = "strongSwan" Message-Authenticator = ... Note there exists an "EAP-Message" attribute. If strongswan is configured with "eap_start = yes" the EAP-Message won't be included and freeradius will immediately reject the request since it contains no credentials. freeradius should then determine: [eap] EAP packet type response id 0 length 15 [eap] No EAP Start, assuming it's an on-going EAP conversation ++[eap] = updated +} # group authorize = updated Found Auth-Type = EAP # Executing group from file /etc/freeradius/sites-enabled/postmates +group authenticate { [eap] EAP Identity [eap] processing type mschapv2 rlm_eap_mschapv2: Issuing Challenge If the eap module isn't in the freeradius authorize{} section, you won't see "Found Auth-Type = EAP" here, and the request will be rejected.
From there the logs will indicate freeradius is sending an Access-Challenge, which strongswan forwards to the IKEv2 initiator. The response should result in another Access-Request being received by freeradius, which includes this time a much longer EAP-Message. Since this is all EAP tunneled in RADIUS (RFC3579), every message should have an EAP-Message. Never will there be any sort of credential in a RADIUS attribute.
Once again, thanks for the help. Sometimes it's the little details :)
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
On Mar 16, 2018, at 3:57 PM, Brian Julin <BJulin@clarku.edu> wrote:
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.
That should work.
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
The alleged "loop" is likely a configuration issue on their end. I've tested FR with EAP-Start packets since the day we supported EAP. There is no "hardcoded forwarding loop". The whole source is available FFS. Anyone can read the FR source and verify that there's no "hardcoded forwarding loop" for EAP-Start. FR just returns an EAP Identity request. Alan DeKok.
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.
On Mar 16, 2018, at 2:11 PM, Phil Frost <phil@postmates.com> wrote:
When strongswan is configured to use the eap-radius plugin, there is no additional configuration for strongswan to indicate what EAP method should be used. Please excuse my ignorance as I'm still learning these things, but isn't the EAP protocol initiated by the authenticator, in this case strongswan, and by proxy, freeradius?
No. EAP is initiated by Strongswan. FreeRADIUS just receives what Strongswan is sending.
From RFC 5996 (IKEv2), section 2.16:
Utterly irrelevant.
From what I can gather from the logs and packet captures, at this point strongswan sends an Access-Request to freeradius containing the identity but no credentials (because they don't yet exist). It's reasonable to then wonder if it's now the responsibility of freeradius to initiate the EAP exchange and request the peer to provide the necessary credentials.
Not in your case. There's no authentication attributes in the packet. i.e. no EAP-Message. No User-Password. No MS-CHAP-Password, etc. No amount of poking FreeRADIUS will cause Strongswan to add those attributes to the packet. Only Strongswan can create those attributes.
Is this not the case? Again please excuse the ignorance -- between IKEv2, RADIUS, EAP, all the various EAP methods, strongswan, freeradius, and each their myriad plugins, it's quite difficult to even understand how these protocols should be working together.
The RADIUS client (e.g. Strongswan) creates things, and sends them to the RADIUS server.
Even just a quick example of a working integration between strongswan and freeradius from someone who has done it before would be very valuable.
FreeRADIUS will authenticate any known user. It doesn't matter what the client is. The client can be PPPoE, a WiFi access point, VPN, or Strongswan. 99.99% of the configuration of FreeRADIUS is *identical*: - add a known user - add a password for that user (ideally Cleartext-Password for testing) - for EAP methods, add CA, server cert That's it for the *server side* of things. 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*. Go ask the Strongswan people how to configure their software. As soon as it's sending packets with EAP-Message or MS-CHAP-... attributes, then come back and ask us for help with FreeRADIUS. Until the client sends the right data, you're just wasting your time trying to muck with FreeRADIUS. It won't help, and it will just get you confused. Ignore FreeRADIUS and all of it's configuration. Concentrate on Strongswan. Alan DeKok.
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.
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.
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
karthik kumar <kumarkarthikn@gmail.com> wrote:
I am setting up 2factor auth and we use Strongswan as our VPN server. I use FreeRADIUS as backend of Strongwan.
This is the setup mac osx (ikev2 with eap-mschapv2) ---> Strongswan ---> FreeRADIUS --> multiotp
Speaking of this, how does this plumbing work (if it does). AFAICT no VPN clients provide a way to integrate 2factor prompts with IKEv2 (those that do, rely on IKEv1 XAuth). At best you could pull it off with a password/username append trick assuming FR had access to cleartext passwords, which, if you are backed by AD, generally won't be the case. ...and trying to figure that out from the multiotp webpages is like searching for a needle in a pile of glass, by hand.
participants (4)
-
Alan DeKok -
Brian Julin -
karthik kumar -
Phil Frost