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.