3.2.x: clients read from SQL still ignore require_message_authenticator / limit_proxy_state (#5378)

8 Oct 2026

      Hi,

I'm running FreeRADIUS 3.2.5 (Ubuntu 24.04 package) with clients loaded
from the
nas table (rlm_sql, read_clients = yes, stock client_query). The NASes are
MikroTik
routers. In radiusd.conf:

    security {
        require_message_authenticator = yes
        limit_proxy_state = auto
    }

These settings don't apply to clients read from SQL. They do apply to
clients from
clients.conf. Hand-built Access-Requests (radclient always adds
Message-Authenticator,
so I built the packets myself), sent from the same IP, defined either as a
nas row or
as a clients.conf client:

  Client defined as a nas row (SQL):
  - no Message-Authenticator: answered
  - no Message-Authenticator, with Proxy-State: answered
  - with Message-Authenticator: answered

Client defined in clients.conf with require_message_authenticator = yes:
  - no Message-Authenticator: dropped
  - no Message-Authenticator, with Proxy-State: dropped
  - with Message-Authenticator: answered

Client defined in clients.conf with require_message_authenticator = auto:
  - no Message-Authenticator: answered
  - no Message-Authenticator, with Proxy-State: dropped
  - with Message-Authenticator: answered

This is GitHub issue #5378 ("Blast parameters does not work for SQL
clients"). It was
closed after ef5e6560 ("inherit from the main dynamic client definition"),
and the
last comment there says SQL clients inherit the global settings. As far as
I can
tell from the current v3.2.x branch, that commit only changed
client_afrom_request()
(dynamic clients). SQL clients still go through:

- rlm_sql.c, generate_sql_clients(): client_afrom_query(..., server, false);
  so require_ma is always false;
- client.c, client_afrom_query(): require_ma comes from that argument, and
  limit_proxy_state is never set, so it stays at its talloc_zero value.

So even on 3.2.6 to 3.2.8, an SQL client seems to get neither setting.

Questions:

1. Am I reading this right? If so, would a patch that makes
client_afrom_query()
   start from main_config.require_ma and main_config.limit_proxy_state (the
way
   client_afrom_cs() does) be accepted? Optional per-client columns in
client_query
   could come on top of that. I can open a new issue or a PR.

2. Until then, I'm planning to enforce it in unlang, first thing in
authorize,
   with a per-NAS flag in the nas table (set for NASes whose firmware sends
   Message-Authenticator):

       authorize {
           if (&Proxy-State && !&Message-Authenticator) {
               do_not_respond
           }
           if (!&Message-Authenticator && "%{sql:SELECT
require_message_auth FROM nas WHERE nasname = '%{Packet-Src-IP-Address}'}"
== "1") {
               do_not_respond
           }
           ...
       }

   Is that a sound workaround, or does it miss something? For example, is a
reply
   ever sent before authorize runs, or are there other packet types I
should cover
   the same way?

I know moving the clients to clients.conf would work. I'd like to keep them
in SQL
because a web panel manages the NAS list.

Thanks,
Kushal Gupta