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