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.