Can I gracefully handle radius requests if all home servers are down?
Hello, Is it possible to detect that home server is not available and gracefully process radius request locally? I tried to use `Post-Proxy-Type Fail-Authentication {}` section but it seems that FreeRadius server will not expect ``` update control { Auth-Type := Accept } ``` instruction in that section and reject request. This is a fragment from debug log ``` (30) Post-Proxy-Type Fail-Authentication { (30) update reply { (30) Tunnel-Type := VLAN (30) Tunnel-Medium-Type := IEEE-802 (30) Tunnel-Private-Group-id := 333 (30) Idle-Timeout := 1800 (30) } # update reply = noop (30) update control { (30) Auth-Type := Accept (30) } # update control = noop (30) } # Post-Proxy-Type Fail-Authentication = noop (30) There was no response configured: rejecting request (30) Using Post-Auth-Type Reject ``` -- Vladimir
I figure out that I can use `fallback` option in `home_server_pool` section, and point it to virtual server in which I can process requests as I want. But this approach works only for radius requests that was arrived after proxy FreeRadius decided that all home servers are dead and start using fallback. So this approach solve one half of my problem. I am still looking for a way to process radius requests if home servers are not responding, but FreeRadius server thinks that its alive. -- Valdimir On Fri, 7 Jun 2019 at 23:10, work vlpl <thework.vlpl@gmail.com> wrote:
Hello,
Is it possible to detect that home server is not available and gracefully process radius request locally? ...
At my previous job I cached all access-accepts in a local database as part of the post-proxy including any custom VSAs the home server sent and encrypted the password. Then when the home server was went down the failover server kicked in and the end users were still able to auth and kept on working. Then I had aggressive timeouts of 2 seconds and then a backoff of 2 mins to make sure the home server was back alive. The only gotcha was to make sure that the destination server either supported Status Messages so I can use those for keepalive or they provided a static username & password to test when the server came back online. Worked well in FR3 3.0.16/7 as I found a few minor bugs in the proxying code in 3.0.14. It's all documented in the proxy and realms config. On Sat, Jun 8, 2019 at 6:06 AM work vlpl <thework.vlpl@gmail.com> wrote:
I figure out that I can use `fallback` option in `home_server_pool` section, and point it to virtual server in which I can process requests as I want. But this approach works only for radius requests that was arrived after proxy FreeRadius decided that all home servers are dead and start using fallback. So this approach solve one half of my problem.
I am still looking for a way to process radius requests if home servers are not responding, but FreeRadius server thinks that its alive. -- Valdimir
On Fri, 7 Jun 2019 at 23:10, work vlpl <thework.vlpl@gmail.com> wrote:
Hello,
Is it possible to detect that home server is not available and gracefully process radius request locally? ...
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jun 7, 2019, at 2:05 PM, work vlpl <thework.vlpl@gmail.com> wrote:
I figure out that I can use `fallback` option in `home_server_pool` section, and point it to virtual server in which I can process requests as I want. But this approach works only for radius requests that was arrived after proxy FreeRadius decided that all home servers are dead and start using fallback. So this approach solve one half of my problem.
I am still looking for a way to process radius requests if home servers are not responding, but FreeRadius server thinks that its alive.
Use 3.0.19. Then, in the "post-proxy" section, add: Post-Proxy-Type Fail { ... add fail rules here } Alan DeKok.
On Sat, 8 Jun 2019 at 12:50, Alan DeKok <aland@deployingradius.com> wrote:
Use 3.0.19. Then, in the "post-proxy" section, add:
Post-Proxy-Type Fail { ... add fail rules here }
I am using FreeRADIUS Version 3.0.20 (git #ba62e22), and from my tests I think that the way you proposed probably will not work. I tried to use this statement ``` update control { Auth-Type := Accept } ``` in `Post-Proxy-Type Fail-Authentication {}` or `Post-Proxy-Type Fail {}`. In both sections it does not work. In debug log I see that `control:Auth-Type` attribute was updated. But it does not change anything, proxy FreeRadius server still want to return `Access-Reject` and go to `Post-Auth-Type REJECT` section. In `control` attributes list I see other attribute `Post-Auth-Type` that probably has precedence. But if I try to use configuration that update this attribute ``` update control { Post-Auth-Type := Accept } ``` FreeRadius server even don't want to start, And says ``` testing-stie[226]: Unknown or invalid value "Accept" for attribute Post-Auth-Type ``` I believe it is because of this https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/share/dictionary... So, let me ask these questions for clarification. 1. To force FreeRadius server send `Access-Accept` radius response usually I should use this statement, isn't it? update control { Auth-Type := Accept } 2. Is `control:Auth-Type` attribute does not matter in `Post-Proxy-Type Fail-Authentication{}`, `Post-Proxy-Type Fail {}` and in `Post-Auth-Type REJECT` sections? And FreeRadius uses `Post-Auth-Type` to control request processing flow? 3. I found this in documentation "Changes to Post-Auth-Type during post-auth will have no effect." https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/doc/configuratio... And in debug log I see next lines ``` (1) } # Post-Proxy-Type Fail-Authentication = noop (1) Login incorrect (Home Server failed to respond): [testing_remote_attr] (from client testclient port 0) (1) There was no response configured: rejecting request (1) Using Post-Auth-Type Reject ```` I tried to set `Post-Auth-Type := Local` inside `Post-Proxy-Type Fail` section but as documentation says https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/doc/configuratio... `Post-Auth-Type` is overwritten automatically and value that I set inside `Post-Proxy-Type Fail` does not matter. Is this means that it is impossible to control value of `Post-Auth-Type` and it will always be set automatically? If not, can I update `Post-Auth-Type` with `Local` or `Challenge`? I mean I definitely can do that, I tested it. But what these values means? How I can control packet processing flow with that attributes? -- Vladimir
On Jun 8, 2019, at 8:40 AM, work vlpl <thework.vlpl@gmail.com> wrote:
On Sat, 8 Jun 2019 at 12:50, Alan DeKok <aland@deployingradius.com> wrote: I am using FreeRADIUS Version 3.0.20 (git #ba62e22), and from my tests I think that the way you proposed probably will not work.
It will work as I said. I don't understand the need to ask questions, and then argue with the answers. This is rude, and it wastes everyones time.
I tried to use this statement
``` update control { Auth-Type := Accept } ```
Which is information you *didn't* give in your previous message. If you ask the wrong question, you get the wrong answer. FreeRADIUS can't turn an Access-Reject reply from a home server into an Access-Accept. If you had asked about *that* in your original message, you would have received that answer.
in `Post-Proxy-Type Fail-Authentication {}` or `Post-Proxy-Type Fail {}`. In both sections it does not work. In debug log I see that `control:Auth-Type` attribute was updated. But it does not change anything, proxy FreeRadius server still want to return `Access-Reject` and go to `Post-Auth-Type REJECT` section. In `control` attributes list I see other attribute `Post-Auth-Type` that probably has precedence. But if I try to use configuration that update this attribute
``` update control { Post-Auth-Type := Accept } ``` FreeRadius server even don't want to start, And says
``` testing-stie[226]: Unknown or invalid value "Accept" for attribute Post-Auth-Type ```
I believe it is because of this https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/share/dictionary...
It's because you're inventing things. You can't just invent new configuration items for the server and expect them to work.
So, let me ask these questions for clarification.
1. To force FreeRadius server send `Access-Accept` radius response usually I should use this statement, isn't it?
update control { Auth-Type := Accept }
If it's not proxying, yes.
2. Is `control:Auth-Type` attribute does not matter in `Post-Proxy-Type Fail-Authentication{}`, `Post-Proxy-Type Fail {}` and in `Post-Auth-Type REJECT` sections?
If you read the documentation and examples Auth-Type affects the *authentication* phase. i.e. the "authenticate" section. Since "Post-Proxy" != "authenticate", then "Auth-Type" doesn't affect the post-proxy phase. This should be fairly clear from the names.
And FreeRadius uses `Post-Auth-Type` to control request processing flow?
In the "post-auth" phase.
3. I found this in documentation "Changes to Post-Auth-Type during post-auth will have no effect." https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/doc/configuratio... And in debug log I see next lines
``` (1) } # Post-Proxy-Type Fail-Authentication = noop (1) Login incorrect (Home Server failed to respond): [testing_remote_attr] (from client testclient port 0) (1) There was no response configured: rejecting request (1) Using Post-Auth-Type Reject ````
I tried to set `Post-Auth-Type := Local` inside `Post-Proxy-Type Fail` section but as documentation says https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/doc/configuratio... `Post-Auth-Type` is overwritten automatically and value that I set inside `Post-Proxy-Type Fail` does not matter. Is this means that it is impossible to control value of `Post-Auth-Type` and it will always be set automatically?
If the documentation says it can't be set then it can't be set. That should also be fairly clear.
If not, can I update `Post-Auth-Type` with `Local` or `Challenge`? I mean I definitely can do that, I tested it. But what these values means? How I can control packet processing flow with that attributes?
The server works as documented. If you want to do something else, either follow the documentation, or change the source code. Alan DeKok.
On Sun, 9 Jun 2019 at 20:48, Alan DeKok <aland@deployingradius.com> wrote:
I am sorry if my messages seemed rude, I clearly didn't mean to do that. I believe that in my first message in this thread http://lists.freeradius.org/pipermail/freeradius-users/2019-June/095600.html I clearly show my intentions to convert `Reject` response from proxy server to `Accept`. Then I take you answer about using `Post-Proxy-Type Fail` section, tried it, it didn't works for me, so I tried to dig deeper and ask additional questions about my findings. Anyway. thank you for answers, now I know that it is impossible to convert `Access-Reject` to `Access-Accept` response that was received from home server. -- Vladimir
participants (3)
-
Alan DeKok -
Peter Lambrechtsen -
work vlpl