Strongswan integration, Access-Request contains no credentials?

[Phil Frost]

On Fri, Mar 16, 2018 at 2:41 PM Brian Julin <BJulin at 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 :)