Clarifications on expected behavior when using proxy-inner-tunnel (3.x)

[Brian Julin]

I don't know whether to rely on this behavior, because it seems a bit
convoluted.

In a server configured to proxy inner tunnel requests the requests flow
as expected between the outer server and the client until PEAP starts
unwrapping.

Then the packet flow seems to be this:

1) normal client -> (outer-eap) -> outer server -> peap ->
2) proxy-inner-tunnel server autz (sets Proxy-To-Realm)
3) proxy-inner-tunnel server ("sends reply" back to outer)
4) either outer pre-proxy section or pre-proxy from a realm virtual_server directive
5) request actually sent to external inner
6) either outer post-proxy section or post-proxy from a realm virtual_server directive
7) outer post-auth

proxy-inner-tunnel's post-auth never gets run, and its pre-proxy/post-proxy will not
get run unless you use a realm "virtual_server" directive to force it.

If this is set up naively without an "eap" in outer's post-proxy section and with
no realm virtual_server directive, the administrator will find inner tunnel replies being
sent directly to the client.   If you do provide a post-proxy in the outer server or a
realm virtual_server directive, everything ends up "working" minus not running
some sections of the proxy-inner-tunnel server.

3,4,5 look like this:
(7) Debug:     authorize {
(7) Debug:       update control {
(7) Debug:         Proxy-To-Realm := "idpi"
(7) Debug:       } # update control = noop
(7) Debug:     } # authorize = noop
(7) Debug: } # server eduroam_idp_proxy
(7) Debug: Virtual server sending reply
(7) Debug: eap_peap: Got tunneled reply code 0
(7) Debug: eap_peap: Tunnelled authentication will be proxied to idpi
(7) Debug: eap: Tunneled session will be proxied.  Not doing EAP
(7) Debug:     modsingle[authenticate]: returned from eap (rlm_eap) for request 7
(7) Debug:     [eap] = handled
(7) Debug:   } # authenticate = handled
(7) Debug: Empty pre-proxy section in virtual server "eduroam_idp_in".  Using default return values.
(7) Debug: proxy: Trying to allocate ID (0/2)
(7) Debug: proxy: Trying to open a new listener to the home server
(7) Debug: proxy: Trying to allocate ID (1/2)
(7) Debug: proxy: request is now in proxy hash
(7) Debug: proxy: allocating destination X.X.X.X port 1812 - Id 149
(7) Debug: Proxying request to home server X.X.X.X port 1812 timeout 30.000000

If that's the way it is supposed to work, as long as I can get my session-state
handling straight, I'm happy to do it that way, but it looked odd so I didn't want
to rely on it without asking.  Also the default mods-available/proxy-inner-tunnel
could use some commentary to this effect.