Can FreeRADIUS proxy accounting requests to multiple systems?

Sylvain Robitaille syl at alcor.concordia.ca
Thu Jun 12 20:58:55 CEST 2008


Me again ...

I have two FreeRADIUS-2.0.3 systems provinding AAA for our wireless
networks and a couple of other (less widely used) services.  The NAS
devices are configured with both, and which one is likely receive
access-request or accounting-request packets at any given time from any
given NAS is essentially undefined (though they appear to be functioning
in a mostly failover fashion, rather than any sort of load-balancing,
given that there is a large majority of traffic going to one of the two
FreeRADIUS servers).

I'm looking to have both of these systems proxy incoming accounting
data to each other, so that they both have complete, up-to-date data
regarding which users are presently authenticated on which services, but
I'd also like to have them proxy the accounting data to a third system
(commercial "appliance" type of system, though I understand that it does
use FreeRADIUS as its RADIUS server) which might act as our wireless
network management system (we're presently evaluating it).

It would use this accounting data to correlate end-user systems (by MAC
addresses obtained from NAS devices) with user account names (from the
RADIUS accounting data).

I've been trying to understand the comments in
raddb/sites-available/copy-acct-to-home-server, raddb/proxy.conf, and
the relevant parts of raddb/radiusd.conf, but I'm not sure I have yet
understood whether what I want can be done: proxy accounting-request
packets from both "production" RADIUS servers to each other AND to the
wireless network management system (though I expect that the NMS would
get from each RADIUS server only accounting-request packets that weren't
already proxied from the partner RADIUS server, to avoid it receiving
duplicate data).

I've started setting up proxy.conf as indicated below my signature, and I
expect I'll need a sites-enabled/copy-acct-to-home-server, but I'm pretty
sure that the proxy.conf as I now have it would not proxy the requests
to both the partner RADIUS server and the wireless network management
system at the same time (not "failover" nor "load-balance", but proxy
to both simultaneously).  I'm hoping that someone can offer guidance.


Desired flow of accounting-request packets:

                                     +---------+
                               +---->| RADIUS2 |
    +-----+     +---------+    |     +---------+
    | NAS |---->| RADIUS1 |----+
    +-----+     +---------+    |     +---------+
                               +---->| WIFINMS |
                                     +---------+
     OR
                                     +---------+
                               +---->| RADIUS1 |
    +-----+     +---------+    |     +---------+
    | NAS |---->| RADIUS2 |----+
    +-----+     +---------+    |     +---------+
                               +---->| WIFINMS |
                                     +---------+

-- 
----------------------------------------------------------------------
Sylvain Robitaille                              syl at alcor.concordia.ca

Systems and Network analyst                       Concordia University
Instructional & Information Technology        Montreal, Quebec, Canada
----------------------------------------------------------------------

--- old/proxy.conf.20080612     2008-03-27 12:47:55.000000000 -0500
+++ proxy.conf  2008-06-12 13:16:39.000000000 -0400
@@ -57,7 +57,7 @@
         #
         #  allowed values: {yes, no}
         #
-       default_fallback = no
+       default_fallback = yes

  }

@@ -114,7 +114,7 @@
         #       acct      - Handles Accounting-Request packets
         #       auth+acct - Handles Access-Request packets at "port",
         #                   and Accounting-Request packets at "port + 1"
-       type = auth
+       type = acct

         #
         #  Configure ONE OF the following two entries:
@@ -146,7 +146,7 @@
         #  Usually 1812 for type "auth", and  1813 for type "acct".
         #  Older servers may use 1645 and 1646.
         #
-       port = 1812
+       port = 1813

         #
         #  The shared secret use to "encrypt" and "sign" packets between
@@ -306,6 +306,30 @@
         #  Useful range of values: 3 to 10
         num_answers_to_alive = 3
  }
+home_server radius2 {
+       type = acct
+       ipaddr = radius2
+       port = 1813
+       secret = testing123
+       response_window = 20
+       zombie_period = 40
+       revive_interval = 120
+       status_check = status-server
+       check_interval = 30
+       num_answers_to_alive = 3
+}
+home_server wifinms {
+       type = acct
+       ipaddr = wifinms
+       port = 1813
+       secret = testing123
+       response_window = 20
+       zombie_period = 40
+       revive_interval = 120
+       status_check = status-server
+       check_interval = 30
+       num_answers_to_alive = 3
+}


  ######################################################################
@@ -320,7 +344,7 @@
  #  10 'realm" sections, and one "home_server_pool" section to tie the
  #  two together.
  #
-home_server_pool my_auth_failover {
+home_server_pool cu_acct_failover {
         #
         #  The type of this pool controls how home servers are chosen.
         #
@@ -394,6 +418,8 @@
         #  be "acct", or the all have to be "auth+acct".
         #
         home_server = localhost
+       home_server = radius2
+       home_server = wifinms

         #  Additional home servers can be listed.
         #  There is NO LIMIT to the number of home servers that can
@@ -421,7 +447,7 @@
  #DEFAULT       Proxy-To-Realm := "realm_name"
  #
  #
-realm example.com {
+realm DEFAULT {
         #
         #  Realms point to pools of home servers.
  #
@@ -440,8 +466,9 @@
         #  configuration item, instead of specifying both "auth_pool"
         #  and "acct_pool".

-       auth_pool = my_auth_failover
+       #auth_pool = my_auth_failover
  #      acct_pool = acct
+       acct_pool = cu_acct_failover

         #
         #  Normally, when an incoming User-Name is matched against the




More information about the Freeradius-Users mailing list