Phil Mayers wrote:
Sure; it's not strictly relevant here, but what confused me is how the middle bit works - peap bails, but what causes the proxy packet to be emitted? I see how this happens if you bail in "authorize", but not "authenticate".
The proxy handler is independent of authorize / authenticate, IIRC.
I'm not seeing that, or I'm doing something wrong. AFAICT rad_virtual_server only calls post-auth if request->reply->code is set, and for packets which are proxied, it is==0 because the reply hasn't been generated yet.
I'll have to take a look. I've been finalizing 3.0.1, and haven't looked at 2.2.x for a while.
The post-proxy/post-auth code for eap/peap ultimately ends up in eappeap_postproxy and AFAICT only calls post-auth if "fake" is found in REQUEST_DATA_EAP_MSCHAP_TUNNEL_CALLBACK, which is only set for the "proxy inner as non-eap" case?
Yes.
In other words, I think post-auth works for peap proxied inner only if "proxy_tunneled_request_as_eap = no", which is not the case for what I'm trying to do.
Hmm... if that's so, it needs to be fixed. But likely in 3.x, because that code is enormously better. Some changes for 3.1 should make this much easier to do, and remove all of the weird issues around proxying inner tunnel stuff.
The thing I'm actually trying to do is cause the inner eap-mschapv2 requests to be proxied [to another FR process] to free up the outer processing thread ASAP - this relates to the recent issues we and others have been having with peap/ntlm_auth timeouts under load spikes, which seem to be some sort of Samba concurrency issue - I've used packet captures to time the on-wire response times for the MS-RPC calls from winbind, and they're completing in a timely fashion, but something in the fork/exec/ntlm_auth/winbind-pipe sequence is going slow and blocking the request thread pool :o(
Hmm... not nice. That could be fixed another way, but I understand what you're trying to do. v2.x.x has some fixes which let you manually set the timeout for exec / ntlm_auth. If that doesn't work well, there are other fixes.
Throwing hardware at the problem is the other solution, but I have no way of knowing if this will solve or hide the problem - it could come back at any time, and I really want to understand the cause (e.g. is it the load of fork/exec or does ntlm_auth/winbind have some kind of built-in concurrency issue?)
The load of fork / exec shouldn't be a problem. Perhaps a better solution would be to run ntlm_auth in "pipe" mode. That would remove the fork/exec issue, and perhaps allow for greater concurrency. Alan DeKok.