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