issues with radius proxy settings

[Alan DeKok]

On Aug 20, 2019, at 8:47 PM, Prem Khanal <prem.khanal at n4l.co.nz> wrote:
> I am running freeradius 3.0.16 on ubuntu 18.04 as a proxy server.

  You may want to upgrade to 3.0.19.  Use the packages at http://packages.networkradius.com

> The setup
> is as such that
> Device enrollment management system forwards radius accounting packets to
> radius proxy and then radius proxy server forwards the accounting packets
> to one or multiple Fortigates accepting radius accounting packets.

  OK.

> The issue I am having is when one of the Fortigate is not able to accept
> packets ( network level issue or firewall level issue ), the proxy server
> starts creating detail and detail.work files and as soon as the Fortigate
> interface is up it (Radius proxy) tries to push the backlog from these
> files.

  That's standard.

> The problem is, if the interface has been down for couple of hours
> the backlog is so huge ( and new requests are frequently coming ) that it
> can not redirect current traffic to specific firewall.

  What do you mean by "cannot redirect current traffic"?

  But it's pretty bad when critical systems are offline for hours.  We recommend keeping critical systems up, so that issues like this don't come up.

> If I delete the
> detail and detail.work file and restart the free radius server then it
> starts functioning normally. I believe I am missing some configuration.
> Kindly guide me what could be the workaround for this.

  Workaround for...

> I am looking for following solution:
> 
> 1. Is there any way to setup a notification as soon as freeradius proxy
> marks a fortigate as Zombie?

  See raddb/trigger.conf.  You can send an SNMP trigger, or do anything else.

> 2. The proxy just stops functioning ( even though it is trying to process
> detail and detail.work files in the background ) i.e. stops forwarding
> accounting packets to specific firewalls  even after the communication
> issue is resolved. How can we make it more resilient?

  Ah.  That's a clearer description of the issue.

  FreeRADIUS shouldn't just stop proxying.

> ====================Proxy.conf=================

  We don't need to see the configuration files.

> ==============================================
> ==========copy-acct-to-home-server========

  Hmm... if you're using that virtual server, then that may be the problem.

  What you may be doing is *always* writing accounting packets to the detail file.  Then, reading the detail file, and sending those packets upstream.

  As you noticed, if the detail file gets huge, then the delay for proxied packet also gets huge.  The solution is to use the "robust-proxy-accounting" virtual server.

  That virtual server will proxy packets, and then *only* write them to the detail file if the home server is down.  So once the home server comes back up, new packets will be sent immediately to the home server.

  Alan DeKok.