Accept in Accounting Section
Hi, I have a FreeRADIUS backend–proxy setup which I was previously running on FreeRADIUS 3.2.1 without any issues. After upgrading the backend-proxy to FreeRADIUS 3.2.8, I noticed a change in behavior: for users with static IP addresses, a Message-Authenticator attribute suddenly appears in Accounting-Response packets. This only happens for sessions where the IP address is not present in radippool (i.e. static IP users). Dynamic IP (CGNAT) users do not show this behavior. My configuration has always been the same, and the default behavior did not change on my side. Below is the debug output from the proxy side showing where the Message-Authenticator is added to the Accounting-Response: 56) Proxy-State = 0x323533 (56) Clearing existing &reply: attributes (56) Received Access-Accept Id 3 from 10.2.134.250:1813 to 172.18.0.2:50949 length 43 (56) Message-Authenticator = 0xcb7e447acd6eb189578d5ec25a844b36 (56) Proxy-State = 0x323533 (56) server default { (56) } (56) Sent Accounting-Response Id 253 from 172.18.0.2:1813 to 193.192.126.156:1646 length 38 (56) Message-Authenticator = 0xcb7e447acd6eb189578d5ec25a844b36 (56) Finished request (56) Cleaning up request packet ID 253 with timestamp +5 due to done Below is the relevant part of my accounting configuration. This has been in place for a long time, and I am not sure why accept was originally used here: ippoolv4 { fail = 1 noop = 2 notfound = 3 } if (fail) { accept } if (noop) { accept } if (notfound) { accept } I could not find clear documentation explaining what accept actually does in the accounting section, and how it affects the generated response. My questions are: Does using accept here cause FreeRADIUS to internally treat this as an Access-Accept, even though this is an Accounting-Request? Could this be the reason why an Access-Accept is received from the backend on the accounting port, and why a Message-Authenticator is added to the Accounting-Response? Has the behavior of accept in accounting changed between 3.2.1 and 3.2.8? Any clarification on the semantics of accept in accounting, or pointers to relevant documentation or changelogs, would be greatly appreciated. Thanks in advance.
Its for mitigating Blast Radius Read Here: https://www.blastradius.fail/attack-details On Sat, Dec 27, 2025 at 4:41 PM Erdal Emlik via Freeradius-Users < freeradius-users@lists.freeradius.org> wrote:
Hi,
I have a FreeRADIUS backend–proxy setup which I was previously running on FreeRADIUS 3.2.1 without any issues.
After upgrading the backend-proxy to FreeRADIUS 3.2.8, I noticed a change in behavior:
for users with static IP addresses, a Message-Authenticator attribute suddenly appears in Accounting-Response packets.
This only happens for sessions where the IP address is not present in radippool (i.e. static IP users).
Dynamic IP (CGNAT) users do not show this behavior.
My configuration has always been the same, and the default behavior did not change on my side.
Below is the debug output from the proxy side showing where the Message-Authenticator is added to the Accounting-Response:
56) Proxy-State = 0x323533
(56) Clearing existing &reply: attributes
(56) Received Access-Accept Id 3 from 10.2.134.250:1813 to 172.18.0.2:50949 length 43
(56) Message-Authenticator = 0xcb7e447acd6eb189578d5ec25a844b36
(56) Proxy-State = 0x323533
(56) server default {
(56) }
(56) Sent Accounting-Response Id 253 from 172.18.0.2:1813 to 193.192.126.156:1646 length 38
(56) Message-Authenticator = 0xcb7e447acd6eb189578d5ec25a844b36
(56) Finished request
(56) Cleaning up request packet ID 253 with timestamp +5 due to done
Below is the relevant part of my accounting configuration.
This has been in place for a long time, and I am not sure why accept was originally used here:
ippoolv4 {
fail = 1
noop = 2
notfound = 3
}
if (fail) {
accept
}
if (noop) {
accept
}
if (notfound) {
accept
}
I could not find clear documentation explaining what accept actually does in the accounting section, and how it affects the generated response.
My questions are:
Does using accept here cause FreeRADIUS to internally treat this as an Access-Accept, even though this is an Accounting-Request?
Could this be the reason why an Access-Accept is received from the backend on the accounting port, and why a Message-Authenticator is added to the Accounting-Response?
Has the behavior of accept in accounting changed between 3.2.1 and 3.2.8?
Any clarification on the semantics of accept in accounting, or pointers to relevant documentation or changelogs, would be greatly appreciated.
Thanks in advance. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Dec 27, 2025, at 6:10 AM, Erdal Emlik via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Below is the debug output from the proxy side showing where the Message-Authenticator is added to the Accounting-Response:
It helps to post the *full* debug output, as suggested in all of the documentation. The more you edit it, the harder it is for anyone to help you.
56) Proxy-State = 0x323533 (56) Clearing existing &reply: attributes (56) Received Access-Accept Id 3 from 10.2.134.250:1813 to 172.18.0.2:50949 length 43 (56) Message-Authenticator = 0xcb7e447acd6eb189578d5ec25a844b36 (56) Proxy-State = 0x323533 (56) server default { (56) } (56) Sent Accounting-Response Id 253 from 172.18.0.2:1813 to 193.192.126.156:1646 length 38 (56) Message-Authenticator = 0xcb7e447acd6eb189578d5ec25a844b36 (56) Finished request (56) Cleaning up request packet ID 253 with timestamp +5 due to done
I'm not clear why the server is receiving an Accounting-Request, and then proxying that as an Access-Request. Or maybe it's not doing that, but you've helpfully deleted all of the debug output which shows the outgoing proxied packet.
Below is the relevant part of my accounting configuration.
This has been in place for a long time, and I am not sure why accept was originally used here:
You shouldn't use the "accept" policy in an accounting section. It's wrong. You can't "accept" an accounting request. You should use "ok" instead.
if (fail) { accept
Change this (and the other ones) to "ok".
I could not find clear documentation explaining what accept actually does in the accounting section, and how it affects the generated response.
Because you're not supposed to use it in an accounting section. It's only supposed to be used for Access-Request packets. You also have the "accept" policy in a text file on disk. Go read it. You'll see that it sets the response packet type to Access-Accept. Which makes *no* sense for accounting packets.
Does using accept here cause FreeRADIUS to internally treat this as an Access-Accept, even though this is an Accounting-Request?
FreeRADIUS does what you told it to do. Go read the "accept" policy. It sets the response as Access-Accept, even if it received an Accounting-Request packet.
Could this be the reason why an Access-Accept is received from the backend on the accounting port, and why a Message-Authenticator is added to the Accounting-Response?
If you configure FreeRADIUS to send an Access-Accept in response to an Accounting-Request packet.... then that's what it does. There is no Message-Authenticator added to the Accounting-Response. There's a Message-Authenticator added to an Access-Accept. And that's done automatically for the BlastRADIUS mitigations.
Has the behavior of accept in accounting changed between 3.2.1 and 3.2.8?
No.
Any clarification on the semantics of accept in accounting, or pointers to relevant documentation or changelogs, would be greatly appreciated.
Read the "accept" policy? And notice that it forces the response type to Access-Accept? The server was sending Access-Accept in response to the Accounting-Request packet, even in 3.2.1. Because that's what it was configured to do. The only change in 3.2.8 is that all Access-Accept packets now contain a Message-Authenticator attribute. In summary: the "accept" configuration is wrong, and was always wrong. If you want to know what the "accept" policy does... then go read the policy. Alan DeKok.
participants (3)
-
Alan DeKok -
Erdal Emlik -
Kushal Gupta