Relaying of accounting requests between Freeradius servers
Greetings list, I have finally been able to upgrade my secondary freeradius server to 2.1.3 and I must commend everyone on their hard work, the changes are great :) I am having some trouble but would like to clarify my understanding before posting all my problem details in case I have misunderstood something. My question is independent of server or platform version and addresses the fundamental mechanics of the relaying process. I am using a virtual server setup to proxy accounting requests between 2 servers for mirroring purposes. As I understand the process server 1 receives an accounting request, which it will process according to its accounting section (in my case inserted into a table via the sql module). If successful, it will then proxy the request to server 2, which will also process it according to its own accounting section. Server 2 will then attempt to proxy the request to server 1 as per its proxy configuration, but will fail on a duplicate record, which will stop duplication from occuring. Is my understanding in this correct, that server 1 will send the request to server 2, and server 2 will try to send it to server 1 again but will fail with a duplication error? Many thanks Patric
Hi,
I have finally been able to upgrade my secondary freeradius server to 2.1.3 and I must commend everyone on their hard work, the changes are great :)
any reason why not 2.1.4 ? :-)
Is my understanding in this correct, that server 1 will send the request to server 2, and server 2 will try to send it to server 1 again but will fail with a duplication error?
it should refuse/ignore a packet its seen before.. alan
A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
I have finally been able to upgrade my secondary freeradius server to 2.1.3 and I must commend everyone on their hard work, the changes are great :)
any reason why not 2.1.4 ? :-)
Because there isn't a valid 2.1.4 tar file? Which leads me to the question what's happening with it? The 2.1.4 file that's currently on the download server has a VERSION file specifying 2.1.5. So we've either need a 2.1.5 tar file or a 2.1.4 tar file with a 2.1.4 VERSION file. Hopefully the 2.1.4 tar file that's there now has the 2.1.4 build fixes which were reported (I think it does). -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
John Dennis wrote:
Because there isn't a valid 2.1.4 tar file? Which leads me to the question what's happening with it? The 2.1.4 file that's currently on the download server has a VERSION file specifying 2.1.5. So we've either need a 2.1.5 tar file or a 2.1.4 tar file with a 2.1.4 VERSION file. Hopefully the 2.1.4 tar file that's there now has the 2.1.4 build fixes which were reported (I think it does).
Give me a day or so and I'll release 2.1.5, with some other fixes. I've also started a "continuous integration" test system on git.freeradius.org. It's not public because it's still a hack. But I can now easily test the build process, and quickly release a "pre" version for people to use. Alan DeKok.
A.L.M.Buxey@lboro.ac.uk wrote:
I have finally been able to upgrade my secondary freeradius server to
2.1.3 and I must commend everyone on their hard work, the changes are great :)
any reason why not 2.1.4 ? :-)
2.1.3 was what was available when I downloaded... :) But now that Im onto version 2 it will be much easier to update regularly!
Is my understanding in this correct, that server 1 will send the request to server 2, and server 2 will try to send it to server 1 again but will fail with a duplication error?
it should refuse/ignore a packet its seen before..
Great, implementing suggestion by Ivan, will see if that solves my problem :) Thanks
I have finally been able to upgrade my secondary freeradius server to 2.1.3 and I must commend everyone on their hard work, the changes are great :)
I am having some trouble but would like to clarify my understanding before posting all my problem details in case I have misunderstood something. My question is independent of server or platform version and addresses the fundamental mechanics of the relaying process.
I am using a virtual server setup to proxy accounting requests between 2 servers for mirroring purposes.
As I understand the process server 1 receives an accounting request, which it will process according to its accounting section (in my case inserted into a table via the sql module). If successful, it will then proxy the request to server 2, which will also process it according to its own accounting section. Server 2 will then attempt to proxy the request to server 1 as per its proxy configuration, but will fail on a duplicate record, which will stop duplication from occuring.
Configure server 2 *not* to proxy requests coming from server 1 back to it. And server 1 not to proxy requests coming from server 2 back to it. There is no reason to send them back. if (NAS-IP-Address != server1) { update control { Proxy-To-Realm := server1 } } Ivan Kalik Kalik Informatika ISP
Fantastic Ivan, thats exactly what I was heading towards :) Let me try this and see if my root problem is resolved! Thanks
Configure server 2 *not* to proxy requests coming from server 1 back to it. And server 1 not to proxy requests coming from server 2 back to it. There is no reason to send them back.
if (NAS-IP-Address != server1) { update control { Proxy-To-Realm := server1 } }
Ivan Kalik Kalik Informatika ISP
Morning :) tnt@kalik.net wrote:
Configure server 2 *not* to proxy requests coming from server 1 back to it. And server 1 not to proxy requests coming from server 2 back to it. There is no reason to send them back.
if (NAS-IP-Address != server1) { update control { Proxy-To-Realm := server1 } }
I began attempting to implement this (was trying to figure out where to put it) when I noticed that the proxied accounting requests sent from one server to the other maintains the original NAS-IP-Address, and not the freeradius servers IP address. I then thought that I might be able to update it in the pre-proxy section, but then it occurred to me that I need to preserve the NAS-IP-Address as this is one of the values I need to send in a disconnect request :( Anything else you might be able to suggest? Many thanks Patric
Patric wrote:
I began attempting to implement this (was trying to figure out where to put it) when I noticed that the proxied accounting requests sent from one server to the other maintains the original NAS-IP-Address, and not the freeradius servers IP address. I then thought that I might be able to update it in the pre-proxy section, but then it occurred to me that I need to preserve the NAS-IP-Address as this is one of the values I need to send in a disconnect request :(
Use Client-IP-Address, not NAS-IP-Address. The Client-IP-Address is the source address of the RADIUS packet. NAS-IP-Address is an attribute inside of the RADIUS packet. It can have nearly any value, including 127.0.0.1, or 0.0.0.0. Alan DeKok.
Alan DeKok wrote:
Use Client-IP-Address, not NAS-IP-Address. The Client-IP-Address is the source address of the RADIUS packet. NAS-IP-Address is an attribute inside of the RADIUS packet. It can have nearly any value, including 127.0.0.1, or 0.0.0.0.
Thanks Alan, I will see if I can figure out how to implement this :)
Hi again :) tnt@kalik.net wrote:
Configure server 2 *not* to proxy requests coming from server 1 back to it. And server 1 not to proxy requests coming from server 2 back to it. There is no reason to send them back.
if (NAS-IP-Address != server1) { update control { Proxy-To-Realm := server1 } }
Ok I think I understand this, please advise if I am on the right track or not. Instead of a "realm DEFAULT" in my proxy.conf to proxy all requests, I instead setup something else like "realm PROXYME", and then in my pre-proxy section I setup the following if (Client-IP-Address != other_freeradius_server_ip) { update control { Proxy-To-Realm := PROXYME } } Many thanks Patric
participants (5)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
John Dennis -
Patric -
tnt＠kalik.net