Proxy realms and home_server_pool fallback not working

[Peter Lambrechtsen]

On Tue, Mar 8, 2016 at 3:04 AM, Alan DeKok <aland at deployingradius.com>
wrote:

> On Mar 7, 2016, at 3:22 AM, Peter Lambrechtsen <peter at 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.