issues with radius proxy settings

Mon Aug 26 08:52:28 CEST 2019

Hi Alan,

Thanks for the reply. I have been trying to configure robust proxy account
following the steps in
https://networkradius.com/doc/3.0.10/raddb/sites-available/robust-proxy-accounting.html
.
I have only changed the IP and secret of a home home server to test if the
configuration is working. But the proxy is not happening. Means the
accounting packets are not forwarded to the home server. Then I tried

nmap -sU -p 1813 <home server IP>

which returned a success
===============================================
Starting Nmap 7.60 ( https://nmap.org ) at 2019-08-26 18:34 NZST
Nmap scan report for 14.1.55.78.host.layer2.co.nz (14.1.55.78)
Host is up (0.010s latency).

PORT     STATE         SERVICE
1813/udp open|filtered radacct

Nmap done: 1 IP address (1 host up) scanned in 0.45 seconds
=================================================

I believe I have added the relevant services to sites-enabled and
mods-enabled ( attached are the screen shots ).

[image: image.png]

[image: image.png]

I have tried running freeradius in an extended debug mode by using

strace -Ff -tt freeradius -X 2>&1 | tee strace-freeradius.log

and when checking the log file I couldn't see any attempt to communicate
with the home server specified in robust-proxy-accounting configuration
file. The only entry I found for proxy is ( not sure what does this mean )

[pid 36713] 18:23:42.431513 write(1, "(2)   Proxy-State = 0x3334\n", 27(2)
  Proxy-State = 0x3334

Do I need to update default file to make robust proxy work? All other
settings are default.  Kindly guide me if I am missing some configuration.

Regards
Prem

On Thu, Aug 22, 2019 at 7:02 AM Alan DeKok <aland at deployingradius.com>
wrote:

> 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.
>
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html

-- 
Cheers
Prem
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 9554 bytes
Desc: not available
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20190826/33927a51/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 82525 bytes
Desc: not available
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20190826/33927a51/attachment-0003.png>