Centralized accounting and coa/disconnect
We have several distributed RADIUS servers that have been using the robust-proxy-accounting model to centrally log accounting information into a mysql database. Now we want to use that info for coa/disconnects. In the coa virtual server example, the RADIUS server gets a coa packet, then looks up the required data to form the coa packet to send to the NAS. Is there a way to have the centralized accounting server receive the disconnect packet, lookup the info in that mysql instance, then proxy that to the right source RADIUS server, so that server can send the coa (or disconnect) to the NAS ? Some vendors either only allow one or two RADIUS servers and those servers must be used for auth/accounting. We really don't want that central accounting server performing auth for everything, thus why we want to proxy it locally to the right instance for the NAS. So can something like that work or do we need to come up with plan B ?
On 16/12/2022 01:31, BuzzSaw Code wrote:
Is there a way to have the centralized accounting server receive the disconnect packet, lookup the info in that mysql instance, then proxy that to the right source RADIUS server, so that server can send the coa (or disconnect) to the NAS ?
See the coa-relay virtual server. That looks up the session details in the database and sends the CoA to the correct destination. You may need to modify it to also look up the relevant RADIUS server. Proxy it to the RADIUS server, which can then forward it on to the correct NAS. -- Matthew
On Fri, 16 Dec 2022 at 09:57, Matthew Newton via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
On 16/12/2022 01:31, BuzzSaw Code wrote:
Is there a way to have the centralized accounting server receive the disconnect packet, lookup the info in that mysql instance, then proxy that to the right source RADIUS server, so that server can send the coa (or disconnect) to the NAS ?
See the coa-relay virtual server. That looks up the session details in the database and sends the CoA to the correct destination.
You may need to modify it to also look up the relevant RADIUS server. Proxy it to the RADIUS server, which can then forward it on to the correct NAS.
And be aware when performing the final leg of proxying to the NAS, that some devices do not accept a Proxy-State attribute in a CoA/Disconnect packet, so you must strip it: pre-proxy { update proxy-request { # Some NASs don't like proxied CoA/PoD packets &Proxy-State !* ANY } } (FreeRADIUS does not need this to correlate the reply.)
This is almost working great, I did hit two snags: 1) There is no COA-Packet-DST-IPv6-Address attribute defined in the default dictionary - since there is a COA-Packet-DST-IP-Address should there not also be a COA-Packet-DST-IPv6-Address defined like so ? ATTRIBUTE COA-Packet-DST-IPv6-Address 1117 ipv6addr 2) I added a custom attribute used to pass the actual COA target address over to the distributed radius server, but I found it wasn't being sent over. Using (or misusing) a vendor defined attribute worked, then I recall reading somewhere there are rules about what attributes are passed/proxied and that certain numerical rangers are filtered ? Is that right ? Where are those rules documented ? Is it in the dictionary files somewhere ? On Fri, Dec 16, 2022 at 6:29 AM Terry Burton <terry.burton@gmail.com> wrote:
On Fri, 16 Dec 2022 at 09:57, Matthew Newton via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
On 16/12/2022 01:31, BuzzSaw Code wrote:
Is there a way to have the centralized accounting server receive the disconnect packet, lookup the info in that mysql instance, then proxy that to the right source RADIUS server, so that server can send the coa (or disconnect) to the NAS ?
See the coa-relay virtual server. That looks up the session details in the database and sends the CoA to the correct destination.
You may need to modify it to also look up the relevant RADIUS server. Proxy it to the RADIUS server, which can then forward it on to the correct NAS.
And be aware when performing the final leg of proxying to the NAS, that some devices do not accept a Proxy-State attribute in a CoA/Disconnect packet, so you must strip it:
pre-proxy { update proxy-request { # Some NASs don't like proxied CoA/PoD packets &Proxy-State !* ANY } }
(FreeRADIUS does not need this to correlate the reply.) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Dec 27, 2022, at 10:24 PM, BuzzSaw Code <buzzsaw.code@gmail.com> wrote:
This is almost working great, I did hit two snags:
1) There is no COA-Packet-DST-IPv6-Address attribute defined in the default dictionary - since there is a COA-Packet-DST-IP-Address should there not also be a COA-Packet-DST-IPv6-Address defined like so ?
No. Just use &coa:Packet-DST-IP-Address,
2) I added a custom attribute used to pass the actual COA target address over to the distributed radius server, but I found it wasn't being sent over. Using (or misusing) a vendor defined attribute worked, then I recall reading somewhere there are rules about what attributes are passed/proxied and that certain numerical rangers are filtered ? Is that right ? Where are those rules documented ? Is it in the dictionary files somewhere ?
Read the debug log. Attribute filtering is done in the attr_filter module. Alan DeKok.
On Wed, Dec 28, 2022 at 8:30 AM Alan DeKok <aland@deployingradius.com> wrote:
No. Just use &coa:Packet-DST-IP-Address,
When I tried that in an update request stanza, just after the database query in coa-relay I got an update failed error - "Failed resolving "X" to IPv4 address: Address family for hostname not supported."
On Dec 28, 2022, at 2:36 PM, BuzzSaw Code <buzzsaw.code@gmail.com> wrote:
On Wed, Dec 28, 2022 at 8:30 AM Alan DeKok <aland@deployingradius.com> wrote:
No. Just use &coa:Packet-DST-IP-Address,
When I tried that in an update request stanza, just after the database query in coa-relay I got an update failed error - "Failed resolving "X" to IPv4 address: Address family for hostname not supported."
"X" isn't an IPv4 address. Or, "X" is a host name which has no IPv4 address associated with it. I would suggest posting *actual examples*, and not tiny bits which are edited so much that they make no sense. The server works when you assign IPv4 addresses to the Packet-DST-IP-Address. Always. If it doesn't work, it's because you did something wrong. But you're not saying what you did, so it's a mystery. Alan DeKok.
"X" isn't an IPv4 address. Or, "X" is a host name which has no IPv4 address associated with it.
It sure isn't an IPv4 address, what we have is an IPv6 address which is why I originally asked if an IPv6 specific dictionary item needed to be added to make this work. As for "saying what I did" I've been trying to - without making any other changes to the default configuration and simply testing this on a development host, we did this: In "coa-relay": .. foreach &control:Tmp-String-0 { if ("%{Foreach-Variable-0}" =~ /([^#]*)#(.*)/) { update request { COA-Packet-Type := "%{Packet-Type}" #COA-Packet-DST-IP-Address := "%{1}" COA-Packet-DST-IP-Address := "fd01::2" COA-Acct-Session-Id := "%{2}" # # Add any other attributes here. # # Set the CoA/Disconnect port COA-Packet-DST-Port := 1700 Debug run: Wed Dec 28 20:40:53 2022 : Debug: server coa { # from file /etc/raddb/sites-local/coa-relay Wed Dec 28 20:40:53 2022 : Debug: recv-coa { Wed Dec 28 20:40:53 2022 : Warning: /etc/raddb/sites-local/coa-relay[120]: Please change attribute reference to '&Tmp-String-0 := ...' Wed Dec 28 20:40:53 2022 : Debug: update { Wed Dec 28 20:40:53 2022 : Debug: &control:Tmp-String-0 := "%{sql:SELECT IFNULL(GROUP_CONCAT(CONCAT(nasipaddress,'#',acctsessionid) separator '|'),'') FROM (SELECT * FROM radacct WHERE ('%{User-Name}'='' OR UserName='%{User-Name}') AND ('%{Acct-Session-Id}'='' OR acctsessionid = '%{Acct-Session-Id}') AND AcctStopTime IS NULL) a}" Wed Dec 28 20:40:53 2022 : Debug: } Wed Dec 28 20:40:53 2022 : Warning: /etc/raddb/sites-local/coa-relay[136]: Please change attribute reference to '&COA-Packet-Type := ...' Wed Dec 28 20:40:53 2022 : Warning: /etc/raddb/sites-local/coa-relay[139]: Please change attribute reference to '&COA-Packet-DST-IP-Address := ...' Wed Dec 28 20:40:53 2022 : Error: /etc/raddb/sites-local/coa-relay[139]: Failed resolving "fd01::2" to IPv4 address: Address family for hostname not supported On Wed, Dec 28, 2022 at 3:03 PM Alan DeKok <aland@deployingradius.com> wrote:
On Dec 28, 2022, at 2:36 PM, BuzzSaw Code <buzzsaw.code@gmail.com> wrote:
On Wed, Dec 28, 2022 at 8:30 AM Alan DeKok <aland@deployingradius.com> wrote:
No. Just use &coa:Packet-DST-IP-Address,
When I tried that in an update request stanza, just after the database query in coa-relay I got an update failed error - "Failed resolving "X" to IPv4 address: Address family for hostname not supported."
"X" isn't an IPv4 address. Or, "X" is a host name which has no IPv4 address associated with it.
I would suggest posting *actual examples*, and not tiny bits which are edited so much that they make no sense.
The server works when you assign IPv4 addresses to the Packet-DST-IP-Address. Always.
If it doesn't work, it's because you did something wrong. But you're not saying what you did, so it's a mystery.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Dec 28, 2022, at 3:43 PM, BuzzSaw Code <buzzsaw.code@gmail.com> wrote:
"X" isn't an IPv4 address. Or, "X" is a host name which has no IPv4 address associated with it.
It sure isn't an IPv4 address, what we have is an IPv6 address which is why I originally asked if an IPv6 specific dictionary item needed to be added to make this work.
The normal attribute which contains IPv6 destination address is Packet-Dst-IPv6-Address
In "coa-relay": .. foreach &control:Tmp-String-0 { if ("%{Foreach-Variable-0}" =~ /([^#]*)#(.*)/) { update request { COA-Packet-Type := "%{Packet-Type}"
#COA-Packet-DST-IP-Address := "%{1}"
COA-Packet-DST-IP-Address := "fd01::2" COA-Acct-Session-Id := "%{2}"
# # Add any other attributes here. #
# Set the CoA/Disconnect port COA-Packet-DST-Port := 1700
That looks to be taken from the default configuration. Hmm... the example doesn't handle IPv6 addresses. That's OK, you can just put the IPv6 address into another attribute, and then copy it into into coa:Packet-Dst-IPv6-Address later on in the virtual server. I'll see if I can clean up the example. It seems a bit confusing in places. Alan DeKok.
participants (4)
-
Alan DeKok -
BuzzSaw Code -
Matthew Newton -
Terry Burton