Looking for help in setting up simple (single) accounting relay (forward). Its been awhile since I last used freeradius and I'm use to the old radrelay program. I see that has been replaced with internal based methods. I've read what documents and comments I could find, but haven't been able to see the entire picture. I've set things up but so far no luck at getting the accounting packets forwarded. In keeping with recommended practice, I have modified very little. I edited the proxy.conf file and enabled the copy-acct-to-home-server server. What else do I need to do? Could someone provide a working example configuration? I'm a little shaky on the realm processing. Perhaps that's the issue. The sever log appears to show just a normal (local) receipt of the accounting record: Ready to process requests. rad_recv: Accounting-Request packet from host 127.0.0.1 port 44057, id=153, length=102 Acct-Session-Id = "6000006B" User-Name = "Fnord" NAS-IP-Address = 192.168.3.5 NAS-Port-Id = "32" NAS-Port-Type = Async Acct-Status-Type = Start Connect-Info = "46000 LAPM/V42BIS" Service-Type = Framed-User Framed-Protocol = PPP Framed-IP-Address = 192.168.5.66 Acct-Delay-Time = 0 # Executing section preacct from file /etc/raddb/sites-enabled/default +- entering group preacct {...} ++[preprocess] returns ok [acct_unique] WARNING: Attribute NAS-Port was not found in request, unique ID MAY be inconsistent [acct_unique] Hashing ',Client-IP-Address = 127.0.0.1,NAS-IP-Address = 192.168.3.5,Acct-Session-Id = "6000006B",User-Name = "Fnord"' [acct_unique] Acct-Unique-Session-ID = "cce9407c7efa55eb". ++[acct_unique] returns ok [suffix] No '@' in User-Name = "Fnord", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop ++[files] returns noop # Executing section accounting from file /etc/raddb/sites-enabled/default +- entering group accounting {...} [detail] expand: /var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d -> /var/log/radius/radacct/127.0.0.1/detail-20121001 [detail] /var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d expands to /var/log/radius/radacct/127.0.0.1/detail-20121001 [detail] expand: %t -> Mon Oct 1 20:00:15 2012 ++[detail] returns ok ++[unix] returns noop [radutmp] expand: /var/log/radius/radutmp -> /var/log/radius/radutmp [radutmp] expand: %{User-Name} -> Fnord rlm_radutmp: No NAS-Port seen. Cannot do anything. rlm_radumtp: WARNING: checkrad will probably not work! ++[radutmp] returns noop [sql] expand: %{User-Name} -> Fnord [sql] sql_set_user escaped user --> 'Fnord' [sql] expand: %{Acct-Delay-Time} -> 0 [sql] expand: INSERT INTO radacct (acctsessionid, acctuniqueid, username, realm, nasipaddress, na sportid, nasporttype, acctstarttime, acctstoptime, acctsessiontime, acctauthentic, connectinfo_start, conn ectinfo_stop, acctinputoctets, acctoutputoctets, calledstationid, callingstationid, acctterminatecause, servicetype, framedp rotocol, framedipaddress, acctstartdelay, acctstopdelay, xascendsessionsvrkey) VALUES ('%{Acct-Session-Id}', '%{Acc t-Unique-Session-Id}', '%{SQL-User-Name}', '%{Realm}', '%{NAS-IP-Address}', '%{NAS-Port}', '%{NAS-Port-Type}', '%S', N ULL, '0', '%{Acct-Authentic}', '%{Connect-Info}', '', '0', '0', '%{Called-Station-Id}', '%{Calling-Station-Id}', '', '%{Service-Type}', '%{Framed-Protocol}', '%{Framed-IP-Address}', rlm_sql (sql): Reserving sql socket id: 3 rlm_sql (sql): Released sql socket id: 3 ++[sql] returns ok ++[exec] returns noop [attr_filter.accounting_response] expand: %{User-Name} -> Fnord attr_filter: Matched entry DEFAULT at line 12 ++[attr_filter.accounting_response] returns updated Sending Accounting-Response of id 153 to 127.0.0.1 port 44057 Finished request 0. Cleaning up request 0 ID 153 with timestamp +178 Going to the next request Ready to process requests. TIA, Bill
On Tue, Oct 2, 2012 at 7:14 AM, Bill Schoolfield <bill@billmax.com> wrote:
Looking for help in setting up simple (single) accounting relay (forward). Its been awhile since I last used freeradius and I'm use to the old radrelay program. I see that has been replaced with internal based methods.
I've read what documents and comments I could find, but haven't been able to see the entire picture. I've set things up but so far no luck at getting the accounting packets forwarded.
In keeping with recommended practice, I have modified very little. I edited the proxy.conf file and enabled the copy-acct-to-home-server
There are more than one way to do that. If you don't care whether the packets actually reach the destination or not (highly recommended when the destination is flakey, and you don't have control over it), IMHO it's better to just use rlm_replicate. See raddb/modules/replicate for details.
server. What else do I need to do? Could someone provide a working example configuration? I'm a little shaky on the realm processing. Perhaps that's the issue.
The sever log appears to show just a normal (local) receipt of the accounting record:
Ready to process requests. rad_recv: Accounting-Request packet from host 127.0.0.1 port 44057, id=153, length=102 Acct-Session-Id = "6000006B" User-Name = "Fnord" NAS-IP-Address = 192.168.3.5 NAS-Port-Id = "32" NAS-Port-Type = Async Acct-Status-Type = Start Connect-Info = "46000 LAPM/V42BIS" Service-Type = Framed-User Framed-Protocol = PPP Framed-IP-Address = 192.168.5.66 Acct-Delay-Time = 0 # Executing section preacct from file /etc/raddb/sites-enabled/default +- entering group preacct {...} ++[preprocess] returns ok [acct_unique] WARNING: Attribute NAS-Port was not found in request, unique ID MAY be inconsistent [acct_unique] Hashing ',Client-IP-Address = 127.0.0.1,NAS-IP-Address = 192.168.3.5,Acct-Session-Id = "6000006B",User-Name = "Fnord"' [acct_unique] Acct-Unique-Session-ID = "cce9407c7efa55eb". ++[acct_unique] returns ok [suffix] No '@' in User-Name = "Fnord", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop ++[files] returns noop # Executing section accounting from file /etc/raddb/sites-enabled/default +- entering group accounting {...} [detail] expand: /var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d -> /var/log/radius/radacct/127.0.0.1/detail-20121001 [detail] /var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d expands to /var/log/radius/radacct/127.0.0.1/detail-20121001 [detail] expand: %t -> Mon Oct 1 20:00:15 2012 ++[detail] returns ok
so the packet goes to detail file. Good.
++[unix] returns noop
You don't need this. Just remove/comment-out all references to "unix".
[radutmp] expand: /var/log/radius/radutmp -> /var/log/radius/radutmp [radutmp] expand: %{User-Name} -> Fnord rlm_radutmp: No NAS-Port seen. Cannot do anything. rlm_radumtp: WARNING: checkrad will probably not work! ++[radutmp] returns noop
same for those two
[sql] expand: %{User-Name} -> Fnord [sql] sql_set_user escaped user --> 'Fnord' [sql] expand: %{Acct-Delay-Time} -> 0 [sql] expand: INSERT INTO radacct (acctsessionid, acctuniqueid, username, realm, nasipaddress, na sportid, nasporttype, acctstarttime, acctstoptime, acctsessiontime, acctauthentic, connectinfo_start, conn ectinfo_stop, acctinputoctets, acctoutputoctets, calledstationid, callingstationid, acctterminatecause, servicetype, framedp rotocol, framedipaddress, acctstartdelay, acctstopdelay, xascendsessionsvrkey) VALUES ('%{Acct-Session-Id}', '%{Acc t-Unique-Session-Id}', '%{SQL-User-Name}', '%{Realm}', '%{NAS-IP-Address}', '%{NAS-Port}', '%{NAS-Port-Type}', '%S', N ULL, '0', '%{Acct-Authentic}', '%{Connect-Info}', '', '0', '0', '%{Called-Station-Id}', '%{Calling-Station-Id}', '', '%{Service-Type}', '%{Framed-Protocol}', '%{Framed-IP-Address}', rlm_sql (sql): Reserving sql socket id: 3 rlm_sql (sql): Released sql socket id: 3 ++[sql] returns ok
do you really need sql? If not, comment it out.
++[exec] returns noop
this as well
[attr_filter.accounting_response] expand: %{User-Name} -> Fnord attr_filter: Matched entry DEFAULT at line 12 ++[attr_filter.accounting_response] returns updated Sending Accounting-Response of id 153 to 127.0.0.1 port 44057 Finished request 0. Cleaning up request 0 ID 153 with timestamp +178 Going to the next request Ready to process requests.
copy-acct-to-home-server doesn't run. Either: - you forgot to create the symlink in sites-enabled, OR - the server reads the wrong location. Read the comments on the file again, starting with this comment " # On most systems, this should support file globbing # e.g. "${radacctdir}/detail-*:*" " -- Fajar
Hi, On Mon, Oct 01, 2012 at 07:14:05PM -0500, Bill Schoolfield wrote:
In keeping with recommended practice, I have modified very little.
That's good. For this purpose, you can actually cut out quite a lot - but make sure you've got your config in version control (e.g. git) before you start so that you can easily backtrack if things go wrong.
I edited the proxy.conf file and enabled the copy-acct-to-home-server server. What else do I need to do? Could someone provide a working example configuration? I'm a little shaky on the realm processing. Perhaps that's the issue.
copy-acct-to-home-server reads a detail file and pushes the "packets" into a virtual server for processing. So you need to write to a detail file for it to read. From your debug output it looks like you're using the standard configuration for 'detail', which won't be where copy-acct-to-home-server expects to read it from. Try something like modules/relay_detail: detail relay_detail { detailfile = ${radacctdir}/relay-detail } sites-enabled/default: ... accounting { relay_detail } ... That should get all accounting packets buffered to ${radacctdir}/relay-detail. Then you need to read them and forward them on, so - sites-enabled/copy-acct-to-home-server: server copy-acct-to-home-server { listen { type = detail filename = ${radacctdir}/relay-detail } preacct { update control { Proxy-To-Realm := 'home_realm' } } accounting { ok } } Then make sure your proxy.conf is configured with realm home_realm correctly. proxy.conf: realm home_realm { ... } This should all write accounting packets to the local detail file, then read them and send them over to the home server. If the home server is down, they will buffer up on this system until the home server comes back again. That should mean you don't drop any logs. Run radiusd -X and watch the output. You should see packets coming in (like your original post), but you should also see the detail reader wake up every second or so and check for packets to relay. If you're not seeing that, then you haven't enabled copy-acct-to-home-server correctly. You should then see that pick up packets and process them. Cheers, Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Architect (UNIX and Networks), Network Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
Matthew, Thanks for the detailed followup. I made all your suggested changes, but I'm a little uncertain about the changes to the proxy.conf file. Here is what I added in proxy.conf: home_server myhomeserver { type = acct ipaddr = xxx.xxx.xxx.xxx port = 1813 secret = ?????? } home_server_pool poolit { home_server = myhomeserver virtual_server = copy-acct-to-home-server type = fail-over } realm home_realm { acct_pool = poolit } Is this right? Bill On 10/2/2012 2:58 AM, Matthew Newton wrote:
Hi,
On Mon, Oct 01, 2012 at 07:14:05PM -0500, Bill Schoolfield wrote:
In keeping with recommended practice, I have modified very little.
That's good. For this purpose, you can actually cut out quite a lot - but make sure you've got your config in version control (e.g. git) before you start so that you can easily backtrack if things go wrong.
I edited the proxy.conf file and enabled the copy-acct-to-home-server server. What else do I need to do? Could someone provide a working example configuration? I'm a little shaky on the realm processing. Perhaps that's the issue.
copy-acct-to-home-server reads a detail file and pushes the "packets" into a virtual server for processing. So you need to write to a detail file for it to read. From your debug output it looks like you're using the standard configuration for 'detail', which won't be where copy-acct-to-home-server expects to read it from.
Try something like
modules/relay_detail:
detail relay_detail { detailfile = ${radacctdir}/relay-detail }
sites-enabled/default:
... accounting { relay_detail } ...
That should get all accounting packets buffered to ${radacctdir}/relay-detail. Then you need to read them and forward them on, so -
sites-enabled/copy-acct-to-home-server:
server copy-acct-to-home-server { listen { type = detail filename = ${radacctdir}/relay-detail } preacct { update control { Proxy-To-Realm := 'home_realm' } } accounting { ok } }
Then make sure your proxy.conf is configured with realm home_realm correctly.
proxy.conf:
realm home_realm { ... }
This should all write accounting packets to the local detail file, then read them and send them over to the home server. If the home server is down, they will buffer up on this system until the home server comes back again. That should mean you don't drop any logs.
Run radiusd -X and watch the output. You should see packets coming in (like your original post), but you should also see the detail reader wake up every second or so and check for packets to relay. If you're not seeing that, then you haven't enabled copy-acct-to-home-server correctly. You should then see that pick up packets and process them.
Cheers,
Matthew
On Tue, Oct 02, 2012 at 11:37:31AM -0500, Bill Schoolfield wrote:
Here is what I added in proxy.conf: ... home_server_pool poolit { home_server = myhomeserver virtual_server = copy-acct-to-home-server
Remove the above line. Apart from that, looks OK to me. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Architect (UNIX and Networks), Network Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
To be clear, remove the line below??? virtual_server = copy-acct-to-home-server Does the "update control { Proxy-To-Realm := 'home_realm' } section handle this association for us? Bill On 10/2/2012 12:19 PM, Matthew Newton wrote:
On Tue, Oct 02, 2012 at 11:37:31AM -0500, Bill Schoolfield wrote:
Here is what I added in proxy.conf: ... home_server_pool poolit { home_server = myhomeserver virtual_server = copy-acct-to-home-server
Remove the above line. Apart from that, looks OK to me.
Matthew
I removed this line. Started up the server and I can see that the packets are being sent to the other server. However. I get...
Detail listener /var/log/radius/radacct/relay-detail state running signalled 0 waiting 1.094676 sec Waking up in 0.9 seconds. rad_recv: Accounting-Request packet from host 192.168.111.55 port 1814, id=54, length=278 Received Accounting-Request packet from client 192.168.111.55 with invalid signature! (Shared secret is incorrect.) Dropping packet without response. Going to the next request
so the shared secret is wrong. But I have checked the secret on both sides and it is the same. What else could it be? I'm a little unclear on the remote server's client entry for this relay. Should it be the ip of the freeradius server or should it match the ip of the originating NAS? I have set up both to no avail. Bill On 10/2/2012 12:27 PM, Bill Schoolfield wrote:
To be clear, remove the line below???
virtual_server = copy-acct-to-home-server
Does the "update control { Proxy-To-Realm := 'home_realm' } section handle this association for us?
Bill
On 10/2/2012 12:19 PM, Matthew Newton wrote:
On Tue, Oct 02, 2012 at 11:37:31AM -0500, Bill Schoolfield wrote:
Here is what I added in proxy.conf: ... home_server_pool poolit { home_server = myhomeserver virtual_server = copy-acct-to-home-server
Remove the above line. Apart from that, looks OK to me.
Matthew
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Tue, Oct 02, 2012 at 12:27:48PM -0500, Bill Schoolfield wrote:
To be clear, remove the line below???
virtual_server = copy-acct-to-home-server
Yes - read the documentation in proxy.conf that explains what this line does. You don't want to relay the packet back to yourself.
Does the "update control { Proxy-To-Realm := 'home_realm' } section handle this association for us?
When the packet drops off the bottom of the preacct (and authorize, if used for auth) section, the Proxy-To-Realm config attribute tells the server not to process it locally any more, but to proxy it to the relevant realm configured in proxy.conf. On Tue, Oct 02, 2012 at 01:58:59PM -0500, Bill Schoolfield wrote:
I removed this line. Started up the server and I can see that the packets are being sent to the other server. However. I get...
Detail listener /var/log/radius/radacct/relay-detail state running signalled 0 waiting 1.094676 sec Waking up in 0.9 seconds. rad_recv: Accounting-Request packet from host 192.168.111.55 port 1814, id=54, length=278 Received Accounting-Request packet from client 192.168.111.55 with invalid signature! (Shared secret is incorrect.) Dropping packet without response. Going to the next request
so the shared secret is wrong. But I have checked the secret on both
That's the shared secret between your NAS and this radius server, not the secret between this server and the remote log destination server. Check the shared secret on the NAS and in your clients.conf. Relayed packets will have debug output like Detail listener /var/log/radius/radacct/relay-detail state replied signalled 0 waiting 0.000000 sec detail_recv: Read packet from /var/log/radius/radacct/relay-detail.work and not something indicating it came in over the network, like rad_recv: Accounting-Request packet from host ... port ...
sides and it is the same. What else could it be? I'm a little unclear on the remote server's client entry for this relay. Should it be the ip of the freeradius server or should it match the ip of the originating NAS? I have set up both to no avail.
The client for the remote server is this proxy server, so the client entry on that server should be the (outgoing, if it has more than one) IP address of this server (the client entry secret on the remote server should match the secret on this proxying server's proxy.conf file). e.g. NAS - secret = A this server - clients.conf (NAS IP) secret = A proxy.conf (remote server) secret = B remote server - clients.conf (this server IP) secret = B Cheers, Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Architect (UNIX and Networks), Network Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
participants (3)
-
Bill Schoolfield -
Fajar A. Nugraha -
Matthew Newton