Clarifications on expected behavior when using proxy-inner-tunnel (3.x)
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.
On Nov 6, 2015, at 12:04 PM, Brian Julin <BJulin@clarku.edu> wrote:
I don't know whether to rely on this behavior, because it seems a bit convoluted.
The complexity is because of the protocols. The only way to make it simpler is to prevent people from doing things at certain stages of authentication. Which is a bad idea.
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
Pretty much.
proxy-inner-tunnel's post-auth never gets run,
In v3 it should be run.
and its pre-proxy/post-proxy will not get run unless you use a realm "virtual_server" directive to force it.
Yes. That's because it was just simpler to set it up that way. Patches are welcome. :) We're working on simplifying and re-designing the server core for 3.1 / 3.2. That will make all of this work by design. The current system was cobbled together over time, and is less than perfect.
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.
That shouldn't happen. I'll see if I can fix that. Probably in 3.1 instead of 3.0. But... the default configuration is there for a reason. Changing things is often a bad idea.
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.
Because you're supposed to list "eap" in the post-proxy section of the outer server. It's all there for a reason. It could be better, of course.
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.
You can rely on the default configuration working. You CANNOT rely on deleting things you don't understand... and having it still "do the right thing". The default configuration is there for a reason. Changing it will often break things.
Also the default mods-available/proxy-inner-tunnel could use some commentary to this effect.
As always, patches are welcome. Alan DeKok.
Alan DeKok wrote:
Yes. That's because it was just simpler to set it up that way.
Patches are welcome. :)
We're working on simplifying and re-designing the server core for 3.1 / 3.2. That will make all of this work by design. The current system was cobbled together over time, and is less than perfect.
Thanks, Alan, that makes things much clearer. That being the case, I don't see a way other than the (deprecated) use_tunneled_reply to pop state out of the inner tunnel (barring some other clever trick?), so I hope I'm OK in assuming use_tunneled_reply will be sticking around until after that refactor "hits shelves"?
Alan DeKok wrote:
On Nov 6, 2015, at 3:36 PM, Brian Julin <BJulin@clarku.edu> wrote:
That being the case, I don't see a way other than the (deprecated) use_tunneled_reply to pop state out of the inner tunnel
What doe that mean?
Nevermind I figured it out: In post-proxy, before (but not after) the call to eap, you can get inner attributes out of the inner reply and manually save them to reply:, then in post-auth save those from reply to session-state:. So you can indeed make do without use_tunneled_reply turned on.
participants (2)
-
Alan DeKok -
Brian Julin