Hello, Thanks again for the timely response. I'm still not 100% clear on the way these protocols interact so I made an attempt at diagramming it:
rightauth=eap-radius ------------ IKEv2 ------------ RADIUS --------- | client | -- EAP -- | strong | -- EAP -- | AAA | ------------ ------------ --------- rightauth=eap-radius rightauth2=xauth-radius ------------ IKEv2 ------------ RADIUS --------- | client | -- EAP -- | strong | -- EAP -- | AAA | ------------ ------------ <XAUTH> --------- If this is correct, then that definitely explains what I am seeing in my packet captures. Here is the situation I was hoping for, as the PAP RADIUS proxy won't accept the forwarded EAP packets: rightauth=eap-radius rightauth2=xauth-radius ------------ IKEv2 ------------ RADIUS --------- | client | -- EAP -- | strong | --XAUTH-- | AAA | ------------ ------------ --------- Is there any current plugin configuration that will let me accomplish something like this, or will I have to downgrade my client's configuration back to IKEv1? Cheers, -Kyle On Fri, Dec 22, 2017 at 1:29 PM Noel Kuntze <[email protected]> wrote: > Hi, > > No. > eap-radius encapsulates EAP packets in RADIUS packets. > xauth-eap encapsulates the XAUTH conversation in an EAP conversation in > RADIUS packets. > They do not interact with each other beyond that they are implemented by > the same plugin and use the same configuration files. > The use of either method does not impact the other. > > Kind regards > > Noel > > On 22.12.2017 22:20, Kyle Seever wrote: > > Hi Noel, > > > > Thanks for the quick response. To make sure I understand fully - without > the /xauth-radius/ backend, /eap-radius/ simply encapsulates the EAP > packets originating from the client within the RADIUS protocol back to the > AAA. With /xauth-radius/, it sends XAuth credentials directly to the AAA > via RADIUS (from the documentation: ".. to directly verify XAuth > credentials using RADIUS User-Name and User-Password attributes."). > > > > That's where I picked up the 'translate EAP to XAuth' thought. What > happens to the EAP encapsulation in this exchange? Are the XAuth > credentials still nested within the EAP transfer? > > > > Thanks again, > > -Kyle > > > > On Fri, Dec 22, 2017 at 12:52 PM Noel Kuntze > <[email protected]> wrote: > > > > Hi, > > > > The xauth-radius authentication method encapsulates the XAUTH > credentials in RADIUS packets. It does not translate an EAP conversation to > XAUTH. > > > > Kind regards > > > > Noel > > > > > > On 22.12.2017 21:33, Kyle Seever wrote: > > > Hello, > > > > > > I am currently trying to integrate strongSwan (v5.3.5) with a > PAP-only RADIUS proxy. Currently, I'm using a client profile of IKEv2 with > EAP which connects to strongSwan without issue. strongSwan is configured > with /rightauth=eap-radius/ and /rightauth2=xauth-radius:profile/. My > reading of the eap-radius#xauth < > https://wiki.strongswan.org/projects/strongswan/wiki/EAPRAdius#XAuth> plugin > was such that it would translate the EAP conversation to regular XAuth > credentials sent to the RADIUS backend via the regular User-Name and > User-Password attributes. When I inspect the network traffic, the plugin is > still encapsulating the EAP messages back to the AAA. > > > > > > What am I misunderstanding about the builtin XAuth backend in the > plugin, and what are some options I have going forward? Will I have to > downgrade to traditional XAuth over IKEv1? > > > > > > Thanks in advance, > > > -Kyle > > > >
