Accept in Accounting Section

[Alan DeKok]

On Dec 27, 2025, at 6:10 AM, Erdal Emlik via Freeradius-Users <freeradius-users at 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20251227/7608405f/attachment.sig>