• HA!

  • By (Deleted User)

    Devinator Escribi?3:

    How about this for a next question...

    Inside the TLS tunnel, the EAP-MSCHAPv2 conversation happens between which two entities?


    The supplicant communicates with the authentication server but only after the certificates are verified by the certificate authority.


  • I think I figured it out. Funk might have been right because I was asking specifically about the VLAN-ID setting. I think it is that the Tunnel-Type, Tunnel-Medium-Type and Tunnel-Private-Group-ID attributes come in Access Request messages rather than Access Accept messages. The tunnel is not torn down yet at that point. Maybe I am mistaken about this, though. Joel, Devin or anyone else; is this correct?

  • The Access Request message is going from the AP to the AS. The attributes that will be assigned to a user or user group would be coming from the AS going to the AP (other direction).


  • I see. I dunno what I am doing wrong, then. I'll have to take a look at the SBR configs. Have you ever gotten VLAN-IDs successfully passed by the RADIUS server back to the AP?

  • yep. i have some docs on it. i'll see what i can dig up for you.


    [HiddenEAPIdentity] Section
    The [HiddenEAPIdentity] section of radius.ini allows the known inner identity of EAP/TTLS and EAP/SIM protocols to be included in the Access-Accept message returned in response to an authentication request.

    I think what this is getting at is that the Access-Accept frame, which carries the return-list attributes, has to be for a particular user (obviously), and there's a need to pull that out of the tunneled information since the username that was sent over in the original EAP/Identity-Request was a bogus/unused value. Otherwise, RADIUS wouldn't know which user's RLA's to return in the Access-Accept packet to the AP.


  • Thanks, Devin. I really appreciate that. I am going to try it out soon and I'll post back here when I have it working.

Page 2 of 2