[strongSwan] Integrating strongSwan with a PAP-only RADIUS backend

Noel Kuntze noel.kuntze+strongswan-users-ml at thermi.consulting
Sat Dec 23 01:50:24 CET 2017


Hello,

EAP is not transformed to XAUTH.
XAUTH is IKEv1 only.
EAP is IKEv2 only.
xauth-radius is a type of proxy between the IKEv1 only XAUTH and a RADIUS server to be able to authenticate those IKEv1 clients against a RADIUS server.

Your current arrangement of 
> rightauth=eap-radius
> rightauth2=xauth-radius
does not make sense and does not do anything useful, as the setting in rightauth2 will never be usable, as it only is usable in IKEv1, and the setting in rightauth
is not usable in IKEv1, because it only is usable in IKEv2.

Kind regards

Noel


On 23.12.2017 01:32, Kyle Seever wrote:
> 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 <noel.kuntze+strongswan-users-ml at thermi.consulting> 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 <noel.kuntze+strongswan-users-ml at thermi.consulting> 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
>     >
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20171223/4347791b/attachment.sig>


More information about the Users mailing list