Virtual server pre-proxy section not executed for proxied authentication on v3.0.18 and above

[Alan DeKok]

On Oct 16, 2019, at 11:08 AM, paul.moser at bt.com wrote:
> Thanks. I've run all of our automated tests against a build generated from v3.0.x head and all now pass with the exception of one - this is one that tests a scenario around the use of a fallback server specified in the home server pool as well as a virtual server being assigned the to pool. This isn't a feature we currently have in production but was under development to improve the resilience of our radius infrastructure, the change of behaviour doesn't inconvenience me - in fact I think I might prefer the new behaviour -  but I'll document my observations here in case it's unintended and/or of relevance to someone else.

  OK.

> We have a fallback server configured in a home server pool as well as a virtual server. The fallback server points to a home server that is just a virtual server (as recommend in proxy.conf). The intention of the fallback server is to, in the event of all the real servers that we would normally proxy authentication requests to being down/unreachable, accept any authentication request so valid end users still get service, albeit possibly with some restriction/limitation such as reduced session length, even if that means giving service to some people who we normally wouldn't.
> 
> On v3.0.7 when an access-request is received and all home servers in the auth pool are dead then I see the request proxied to the fallback server, it can update the reply in the post-auth section of the virtual server associated with the fallback server and then the post-proxy section of the virtual server associated with the home server pool is also executed and can update the reply.
> 
> On a head build v.3.0.x it looks the same except the post-proxy section of the virtual server associated with the home server pool is not executed.

  The "fallback-server" is executed, which is what's supposed to happen.  So I think while this is a change, it's the right thing to do.

  The alternative would be to fail over to the "fallback" server, but then *not* run the fallback server.  Which doesn't make a lot of sense.

  Alan DeKok.