On Tue, Mar 8, 2016 at 3:04 AM, Alan DeKok <aland@deployingradius.com> wrote:
On Mar 7, 2016, at 3:22 AM, Peter Lambrechtsen <peter@crypt.co.nz> wrote:
Yes, I have figured that out. I'm now pinging all our downstream radius clients to see which respond to something sane when sent a Status, and then turning on Status server for them.
Or just send Access-Request with a fake username "thisismejusttesting". They'll respond with an Access-Reject, which is good enough to determine that they're alive.
What could I do in Post-Proxy-Type?
Anything you can do anywhere else.
The fallback virtual server is just there for ease of use. But... it complicates the proxy handling, as you've seen. A simpler approach is to put all of the "unlang" handling into... unlang. And not into the proxy code.
As I can't call the virtual server,
We'll fix that for 3.2.
and Proxy-To-Realm doesn't proxy to a new destination nor does setting the control to accept.
The home server pools should take care of fail-over to another home server. But yes, once the whole pool has failed... you can't send the packet to a different destination. That's what home server pools are for...
There doesn't seem to be a way to turn a Reject from a failed proxy request back into an Accept.
A failed proxy request is not really a reject... it's just a failed request. And you can force it to be an Access-Accept via Post-Proxy-Type Fail:
post-proxy { ...
Post-Proxy-Type Fail-Authentication { update control { Response-Packet-Type := Access-Accept }
} ... }
This doesn't seem to work in 3.0.x head, I will test it on 3.1.x tomorrow. (0) ERROR: Failing proxied request for user "peter", due to lack of any response from home server 192.168.1.113 port 1812 (0) Clearing existing &reply: attributes (0) Found Post-Proxy-Type Fail-Authentication (0) # Executing group from file ./sites-enabled/default (0) Post-Proxy-Type Fail-Authentication { (0) update control { (0) Response-Packet-Type := Access-Accept (0) } # update control = noop (0) policy accept { (0) update control { (0) &Response-Packet-Type = Access-Accept (0) } # update control = noop (0) [handled] = handled (0) } # policy accept = handled (0) } # Post-Proxy-Type Fail-Authentication = handled (0) There was no response configured: rejecting request <- How do I configure a response? (0) Using Post-Auth-Type Reject (0) # Executing group from file ./sites-enabled/default (0) Post-Auth-Type REJECT { We'll work on simplifying that for 3.2, also.
Thanks for all your help on this, the fail-over with the second server being the virtual seems to work well, just means I am restricted to a single server and can't use load-balance. But having this config would be my ideal:
home_server_pool ProxyDestPool { type = load-balance home_server = ProxyDest1 home_server = ProxyDest2 home_server = ProxyDest3 fallback = cacheuser }
That works for me. When all home servers in a "load-balance" pool are down, it uses the fallback virtual server:
(0) } # authorize = updated Home server pool example.net failing over to fallback example.net Proxying to virtual server example.net
I think this must work in 3.1 as it doesn't work for me in 3.0.x head from last week, as I just tried this and fallback didn't seem to get applied at all. I'll test 3.1 head tomorrow morning.