Michael Arndt wrote: > i try to get a better grip in understanding the virtual server for inner eap > tunnel.
The TLS-based EAP methods involve setting up a TLS tunnel between the client PC and the RADIUS server. Processing of the TLS tunnel is done by the "default" virtual server. Just the same as CHAP, PAP, EAP-MD5, etc. Once the TLS tunnel is set up, authentication data is sent inside of the tunnel. The server treats this data just as if it was another authentication request, *but* processes it through the "inner-tunnel" virtual server. This allows the inner-tunnel policies to be different from the ones for the "default" virtual server. The policies *should* be different because it's a different kind of authentication: inside of a TLS tunnel. > -The eap module can map tunneled requests to a virtual server ( inner tunnel > ) That's vague to the point of being meaningless. What's "map" ? > - It "knows" where to communicate by freeradius reading the virtual servers > configs in sites-enabled I have no idea what that means. > -So the Port configured for the inner tunnel virtual server (statement valid > only for this inner tunnel VS) > is only relevant wrt external for testing purposes in order to test correct > freeradius config wrt EAP That sounds right. > -freeradius handles the communication to the inner tunnel with the above > mentioned > mapping of the eap module. So in productive use there is no need to reference > the Port for the inner tunnel ( except when proxying or using the test for > EAP to check for a valid config ) No. Proxying has nothing to do with the "listen" section in the inner-tunnel. > -the main goal of the inner tunnel virtual server is to allow > completely independent policies for outer / inner tunneled sessions. Yes. When trying to understand things, keep the descriptions concrete, and fact-based. Saying requests can "map" to something is vague. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html