Post-Proxy-Type Reject handling
Hi, I'm a little bit confused by the change introduced in commit 4b9d325515 ("Set Post-Proxy-Type Reject if the request was rejected by the proxy server") from 19 Dec 2012. I think most users, including me, expect that a Reject reply received from a remote RADIUS server is automatically forwarded by the mediating RADIUS server to the client. But it seems this patch changes the default behaviour. What I'm seeing is that such a Reject reply will be silently discarded and *not* forwarded to the client. This may break a few setups. Sadly, the Post-Proxy-Type "Reject" is not even mentioned anywhere in the example config files. Especially I would suggest adding a hint akin to the "Fail" case in "raddb/sites-available/default". What is the correct move to make FreeRADIUS behave like pre-2.2.1, i.e. just forwarding the proxy reply? I'm guessing I should duplicate my "post-proxy" modules again inside a Post-Proxy-Type Reject {} stanza? Thank you, Julius
On 01/11/13 14:10, Julius Plenz wrote:
Hi,
I'm a little bit confused by the change introduced in commit 4b9d325515 ("Set Post-Proxy-Type Reject if the request was rejected by the proxy server") from 19 Dec 2012.
Confirmed; problematic line seems to be here: https://github.com/FreeRADIUS/freeradius-server/blob/4b9d3255/src/main/event... ...as there are no values defined for Post-Proxy-Type, so the function early-returns. Simple fix is: https://github.com/philmayers/freeradius-server/commit/8fb57474fb70c ...or modify the dictionaries I guess?
On 01/11/13 15:26, Phil Mayers wrote:
...as there are no values defined for Post-Proxy-Type, so the function early-returns.
Simple fix is:
https://github.com/philmayers/freeradius-server/commit/8fb57474fb70c
...or modify the dictionaries I guess?
So, possible solutions are: 1. Define "Post-Proxy-Type = Reject" in the config and replicate your policies there: post-proxy { pol1 pol2 Post-Proxy-Type Reject { pol1 pol2 } } 2. Define the attribute in the dictionaries, and hopefully FreeRADIUS will just process the normal post-proxy section e.g. at the end of raddb/dictionary: VALUE Post-Proxy-Type Reject 999 3. Apply patch at the URL above
Phil Mayers wrote:
Simple fix is:
https://github.com/philmayers/freeradius-server/commit/8fb57474fb70c
That fix was in 3.0, but not in 2.x. <sigh> Alan DeKok.
Hi, * Alan DeKok <aland@deployingradius.com> [2013-11-01 19:41]:
https://github.com/philmayers/freeradius-server/commit/8fb57474fb70c
That fix was in 3.0, but not in 2.x. <sigh>
Okay, thanks. So it was just an oversight rather than intentionally breaking working configs. FTR, I see you pushed a patch similar to Phil's to the v2.x.x branch (commit release_2_2_2-4-ge7c7350). Thanks! Julius
Hi, * Alan DeKok <aland@deployingradius.com> [2013-11-01 19:41]:
That fix was in 3.0, but not in 2.x. <sigh>
If a home server actually rejects a request, then this is successfully proxied with your patch, thanks. However, I'm still having issues with the proxy failure case. Commit 68c7936c02 changed the "no_response_fail" default so that requests that give no answer are re-queued to be tried with a different home server. However this is not really working for me. Worse still, if my first home server is not responding, then it seems the proxied packet never leaves the wait_a_bit() loop and I get an error like WARNING: Unresponsive thread 0 for request 0, in component <core> module and later repeated lines: WARNING: Child is hung for request 0 in component <core> module . What is the server's "exit strategy" in case there is no live home server? I would say "send a reject", but then at some point the server NEEDS to call post_proxy_fail_handler(request) and initiate a cleanup. I cannot see where this is happening. Any help is appreciated, Julius
Julius Plenz wrote:
Worse still, if my first home server is not responding, then it seems the proxied packet never leaves the wait_a_bit() loop and I get an error like
WARNING: Unresponsive thread 0 for request 0, in component <core> module
I'll take a look. The fix should be simple.
What is the server's "exit strategy" in case there is no live home server?
Post-proxy-type "fail".
I would say "send a reject", but then at some point the server NEEDS to call post_proxy_fail_handler(request) and initiate a cleanup. I cannot see where this is happening.
It should be there... Alan DeKok.
Hi Alan, * Alan DeKok <aland@deployingradius.com> [2013-11-07 23:26]:
Worse still, if my first home server is not responding, then it seems the proxied packet never leaves the wait_a_bit() loop and I get an error like
WARNING: Unresponsive thread 0 for request 0, in component <core> module
I'll take a look. The fix should be simple.
Any new developments here? I guess if I want to run 2.2.0, I should simply revert to the old behaviour by setting " no_response_fail = yes" for every home server? Julius
Julius Plenz wrote:
Any new developments here? I guess if I want to run 2.2.0, I should simply revert to the old behaviour by setting " no_response_fail = yes" for every home server?
No new developments. I've been busy with other work. Yes, you can set "no_response_fail = yes" to get the old behavior. Alan DeKok.
Ok pulled down patch and built new server version . I'll see what happens on Monday A Sent from my iPhone
On 1 Nov 2013, at 15:26, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 01/11/13 14:10, Julius Plenz wrote: Hi,
I'm a little bit confused by the change introduced in commit 4b9d325515 ("Set Post-Proxy-Type Reject if the request was rejected by the proxy server") from 19 Dec 2012.
Confirmed; problematic line seems to be here:
https://github.com/FreeRADIUS/freeradius-server/blob/4b9d3255/src/main/event...
...as there are no values defined for Post-Proxy-Type, so the function early-returns.
Simple fix is:
https://github.com/philmayers/freeradius-server/commit/8fb57474fb70c
...or modify the dictionaries I guess? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (4)
-
Alan DeKok -
Alex Sharaz -
Julius Plenz -
Phil Mayers