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

Brian Julin BJulin at
Fri Nov 6 18:04:58 CET 2015

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

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

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.

More information about the Freeradius-Users mailing list