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 :)