- Freeradius-Users - lists.freeradius.org

Running Freeradius in k8s - No reply from server while the server refuses the auth client
by Dan Yasny 26 Feb '25

26 Feb '25

I am trying to deploy a simple freeradius server in an on-prem k8s cluster. Here is my configuration Clients file: root@freeradius-6c7c4d8f68-6x9rg:/# cat /etc/raddb/clients.conf client all { ipaddr = 0.0.0.0 netmask = 0 proto = * secret = testing123 nas_type = other require_message_authenticator = no shortname = all limit { max_connections = 16 lifetime = 0 idle_timeout = 30 } } Users file: root@freeradius-6c7c4d8f68-6x9rg:/# cat /etc/raddb/users testuser Cleartext-Password := "testing1234" Reply-Message := "Hello, %{User-Name}" otheruser Cleartext-Password := "blahblah" Reply-Message := "Hello, %{User-Name}" radiusd.conf: root@freeradius-6c7c4d8f68-6x9rg:/# cat /etc/raddb/radiusd.conf log { destination = files file = /var/log/freeradius/radius.log syslog_facility = daemon } listen { type = auth ipaddr = * port = 1812 } listen { type = acct ipaddr = * port = 1813 } listen { type = control socket = /etc/freeradius/control.sock mode = rw } Test output: $ radtest testuser testing1234 radius.myk8s.local:1812 0 testing123 Sent Access-Request Id 158 from 0.0.0.0:38170 to 10.1.6.66:1812 length 78 User-Name = "testuser" User-Password = "testing1234" NAS-IP-Address = 192.168.1.128 NAS-Port = 0 Message-Authenticator = 0x00 Cleartext-Password = "testing1234" Sent Access-Request Id 158 from 0.0.0.0:38170 to 10.1.6.66:1812 length 78 User-Name = "testuser" User-Password = "testing1234" NAS-IP-Address = 192.168.1.128 NAS-Port = 0 Message-Authenticator = 0x00 Cleartext-Password = "testing1234" Sent Access-Request Id 158 from 0.0.0.0:38170 to 10.1.6.66:1812 length 78 User-Name = "testuser" User-Password = "testing1234" NAS-IP-Address = 192.168.1.128 NAS-Port = 0 Message-Authenticator = 0x00 Cleartext-Password = "testing1234" (0) No reply from server for ID 158 socket 3 Server logs: Listening on auth address * port 1812 Listening on acct address * port 1813 Listening on command file /etc/freeradius/control.sock Ready to process requests Ignoring request to auth address * port 1812 from unknown client 10.1.148.201 port 55669 proto udp Ready to process requests Ignoring request to auth address * port 1812 from unknown client 10.1.148.201 port 55669 proto udp Ready to process requests Ignoring request to auth address * port 1812 from unknown client 10.1.148.201 port 55669 proto udp Ready to process requests What am I missing?

2 1

eapol_test
by BuzzSaw Code 24 Feb '25

24 Feb '25

Is eapol_test still the preferred way to test the various EAP methods ? Or is there a better tool for validating the FreeRADIUS configuration that can be semi-automated ?

2 6

NSAPI changes Acct-Session-Id from upstream provider
by Gabriel Marais 24 Feb '25

24 Feb '25

Hi Guys This might be off topic but I was wondering if someone with more knowledge than me, would be able to confirm the following :- In a mobile network scenario with thousands of IoT devices On our radius servers, we've been noticing a lot of 0-byte sessions on our databases and upon investigation, we've seen the following behaviour :- > Authentication Request Received < Access Accept sent back > Accounting Start Packet Received with a Acct-Session-Id < Acknowledgement sent back > Interim Accounting Packet Received - This time with a different Acct-Session-Id for the same connection ** At this point, things start going bad as we are not able to update the original DB entry created with the Acct Start Packet, since the Acct-Session-Id differs between the packet received in the Accounting Start Packet and the Interim Accounting Packet. This results in a 0-session entry in the DB for the Accounting Start Packet entry as a new entry is written into the DB based on the new Acct-Session-Id received in the Interim Accounting packet. Any subsequent packets received with a different Acct-Session-Id, results in writing a new DB entry when the Interim Accounting Packet is received. We queried this with the upstream provider, and they advised that the 3GPP-NSAPI number changes when packets are received and they claim that the Acct-Session-Id on their side would change based on the 3GPP-NSAPI value that could (and in most cases) changes. < Acknowledgement Sent back >From what I've been reading, The Acct-Session-Id should remain constant for the entire PDP context/session, even when the NSAPI changes because the Acct-Session-Id is meant to uniquely identify the entire user session. NSAPI changes are considered sub-sessions within the main PDP context and keeping the same Acct-Session-Id helps maintain session continuity for billing and tracking purposes, which is exactly our use case for accounting which is not working as expected. Any thoughts and insights would be appreciated if someone faced a similar situation. Many thanks, Gabriel

5 11

Correct way to deal with an 'incorrect' dictionary shipped by default
by Coy Hile (BLOOMBERG/ 919 3RD A) 21 Feb '25

21 Feb '25

Hi, Recently (well, in the last year and a half or so) we got bit by FreeRADIUS shipping a 'dictinary.infinera' that's incorrect. Looking at the file, we see it's for vendor ID 8708 which according to IANA is "Lumentis AB". https://github.com/FreeRADIUS/freeradius-server/blob/master/share/dictionar… The actual Infinera dictionary (as given to our network team by the vendor) contains this data by contrast: # -*- text -*- # Dictiionary for Infinera # # VENDOR Infinera 21296 BEGIN-VENDOR Infinera ATTRIBUTE Infinera-User-Priv-SA 1 integer ATTRIBUTE Infinera-User-Priv-NA 2 integer ATTRIBUTE Infinera-User-Priv-NE 3 integer ATTRIBUTE Infinera-User-Priv-PR 4 integer ATTRIBUTE Infinera-User-Priv-TT 5 integer ATTRIBUTE Infinera-User-Priv-MA 6 integer ATTRIBUTE Infinera-User-Priv-RA 7 integer ATTRIBUTE Infinera-User-Priv-EA 8 integer ATTRIBUTE Infinera-User-SessionTimeout 17 integer ATTRIBUTE Infinera-User-LockedOut 18 integer ATTRIBUTE Infinera-User-CanUseResSession 19 integer ATTRIBUTE Infinera-User-MgtType-EMS 33 integer ATTRIBUTE Infinera-User-MgtType-GNM 34 integer ATTRIBUTE Infinera-User-MgtType-TL1 35 integer ATTRIBUTE Infinera-User-MgtType-CLI 36 integer ATTRIBUTE Infinera-User-MgtType-NETCONF 37 integer ATTRIBUTE Infinera-Rsvd-Str-Attribute1 240 string ATTRIBUTE Infinera-Rsvd-Str-Attribute2 241 string ATTRIBUTE Infinera-Rsvd-Int-Attribute1 249 integer ATTRIBUTE Infinera-Rsvd-Int-Attribute2 250 integer VALUE Infinera-User-Priv-NE NE-NONPRIVILEGED 0 VALUE Infinera-User-Priv-NE NE-PRIVILEGED 1 VALUE Infinera-User-Priv-PR PR-NONPRIVILEGED 0 VALUE Infinera-User-Priv-PR PR-PRIVILEGED 1 VALUE Infinera-User-Priv-TT TT-NONPRIVILEGED 0 VALUE Infinera-User-Priv-TT TT-PRIVILEGED 1 VALUE Infinera-User-Priv-MA MA-NONPRIVILEGED 0 VALUE Infinera-User-Priv-MA MA-PRIVILEGED 1 VALUE Infinera-User-Priv-RA RA-NONPRIVILEGED 0 VALUE Infinera-User-Priv-RA RA-PRIVILEGED 1 VALUE Infinera-User-Priv-EA EA-NONPRIVILEGED 0 VALUE Infinera-User-Priv-EA EA-PRIVILEGED 1 VALUE Infinera-User-CanUseResSession CANNOT-USE-RES-SESSION 0 VALUE Infinera-User-CanUseResSession CAN-USE-RES-SESSION 1 VALUE Infinera-User-MgmtType-EMS MGMTTYPE-EMS-DISALLOWED 0 VALUE Infinera-User-MgmtType-EMS MGMTTYPE-EMS-ALLOWED 1 VALUE Infinera-User-MgmtType-GNM MGMTTYPE-GNM-DISALLOWED 0 VALUE Infinera-User-MgmtType-GNM MGMTTYPE-GNM-ALLOWED 1 VALUE Infinera-User-MgmtType-TL1 MGMTTYPE-TL1-DISALLOWED 0 VALUE Infinera-User-MgmtType-TL1 MGMTTYPE-TL1-ALLOWED 1 VALUE Infinera-User-MgmtType-CLI MGMTTYPE-CLI-DISALLOWED 0 VALUE Infinera-User-MgmtType-CLI MGMTTYPE-CLI-ALLOWED 1 VALUE Infinera-User-MgmtType-NETCONF MGMTTYPE-NETCONF-DISALLOWED 0 VALUE Infinera-User-MgmtType-NETCONF MGMTTYPE-NETCONF-ALLOWED 1 END-VENDOR Infinera That vendor ID according to IANA is actually "Infinera". I've managed to work-around this by putting a hack in our RADIUS dictionary installation workflow to remove the shipped dictionary.infinera file from the shipped dictionary file, but that seems like a hack at bes. It means that someone from my team has to remember to run that workflow every time a box gets touched by patching automation since an updated FreeRADIUS RPM showing up from RedHat--or soon from your official packages--will overwrite our working copy. Is there a better way we should handle this? Thanks, -Coy

4 7

freeradius - TLS1.3 support
by Akhil Pillai 20 Feb '25

20 Feb '25

Hello All, I have been facing an issue with using tls1.3 in the freeradius. I have been using OpenWrt OS 24.10-rc2 hosted on a linksys router 3200acm. I have been using freeradius 3.2.5 and openssl 3.0.15. I am trying to setup a cert based authentication. My client is a linux system. My setup works fine when i set the tls min,max to 1.2 in the eap. Now i wanted to use it with tls1.3 and below is the error message that i am getting at the radius server: (2) Finished request Waking up in 0.1 seconds. (3) Received Access-Request Id 25 from 127.0.0.1:48027 to 127.0.0.1:1812 length 414 (3) Message-Authenticator = 0xc98320007899b6bb4770df4b55e42006 (3) User-Name = "user" (3) NAS-IP-Address = 127.0.0.1 (3) NAS-Identifier = "24f5a2c3707a" (3) Called-Station-Id = "24-F5-A2-C3-70-7A:WIFI_LNK_5G" (3) NAS-Port-Type = Wireless-802.11 (3) Service-Type = Framed-User (3) NAS-Port = 1 (3) Calling-Station-Id = "C0-EE-40-45-49-8C" (3) Connect-Info = "CONNECT 54Mbps 802.11a" (3) Acct-Session-Id = "6F4499DCFDDEF213" (3) Attr-186 = 0x000fac04 (3) Attr-187 = 0x000fac04 (3) Attr-188 = 0x000fac01 (3) Framed-MTU = 1400 (3) EAP-Message = 0x02ff00c40d0016030100b9010000b503036218c045b79856a9894150ad6bbca3a09f0e1cd0191899d60097eb7db525a122000038c02cc030009fcca9cca8ccaac02bc02f009ec024c028006bc023c0270067c00ac0140039c009c0130033009d009c003d003c0035002f00ff01000054000b000403000102000a000c000a001d0017001e001900180016000000170000000d0030002e040305030603080708080809080a080b080408050806040105010601030302030301020103020202040205020602 (3) State = 0xeafcdefdea03d3f8dbd1dcc1dd69fc85 (3) Restoring &session-state (3) &session-state:Framed-MTU = 994 (3) # Executing section authorize from file /etc/freeradius3/sites-enabled/default (3) authorize { (3) policy filter_username { (3) if (&User-Name) { (3) if (&User-Name) -> TRUE (3) if (&User-Name) { (3) if (&User-Name =~ / /) { (3) if (&User-Name =~ / /) -> FALSE (3) if (&User-Name =~ /@[^@]*@/ ) { (3) if (&User-Name =~ /@[^@]*@/ ) -> FALSE (3) if (&User-Name =~ /\.\./ ) { (3) if (&User-Name =~ /\.\./ ) -> FALSE (3) if ((&User-Name =~ /@/) && (&User-Name !~ /(a)(.+)\.(.+)$/)) { (3) if ((&User-Name =~ /@/) && (&User-Name !~ /(a)(.+)\.(.+)$/)) -> FALSE (3) if (&User-Name =~ /\.$/) { (3) if (&User-Name =~ /\.$/) -> FALSE (3) if (&User-Name =~ /(a)\./) { (3) if (&User-Name =~ /(a)\./) -> FALSE (3) } # if (&User-Name) = notfound (3) } # policy filter_username = notfound (3) [preprocess] = ok (3) [chap] = noop (3) [mschap] = noop (3) [digest] = noop (3) suffix: Checking for suffix after "@" (3) suffix: No '@' in User-Name = "user", looking up realm NULL (3) suffix: No such realm "NULL" (3) [suffix] = noop (3) eap: Peer sent EAP Response (code 2) ID 255 length 196 (3) eap: No EAP Start, assuming it's an on-going EAP conversation (3) [eap] = updated (3) [files] = noop (3) [expiration] = noop (3) [logintime] = noop (3) [pap] = noop (3) } # authorize = updated (3) Found Auth-Type = eap (3) # Executing group from file /etc/freeradius3/sites-enabled/default (3) authenticate { (3) eap: Removing EAP session with state 0xeafcdefdea03d3f8 (3) eap: Previous EAP request found for state 0xeafcdefdea03d3f8, released from the list (3) eap: Peer sent packet with method EAP TLS (13) (3) eap: Calling submodule eap_tls to process data (3) eap_tls: (TLS) EAP Got final fragment (190 bytes) (3) eap_tls: WARNING: (TLS) EAP Total received record fragments (190 bytes), does not equal expected expected data length (0 bytes) (3) eap_tls: (TLS) EAP Done initial handshake (3) eap_tls: (TLS) TLS - Handshake state - before SSL initialization (3) eap_tls: (TLS) TLS - Handshake state - Server before SSL initialization (3) eap_tls: (TLS) TLS - Handshake state - Server before SSL initialization (3) eap_tls: (TLS) TLS - recv TLS 1.3 Handshake, ClientHello (3) eap_tls: (TLS) TLS - send TLS 1.2 Alert, fatal protocol_version (3) eap_tls: ERROR: (TLS) TLS - Alert write:fatal:protocol version (3) eap_tls: ERROR: (TLS) TLS - Server : Error in error (3) eap_tls: ERROR: (TLS) Failed reading from OpenSSL: error:0A000102:SSL routines::unsupported protocol (3) eap_tls: ERROR: (TLS) System call (I/O) error (-1) (3) eap_tls: ERROR: (TLS) EAP Receive handshake failed during operation (3) eap_tls: ERROR: [eaptls process] = fail (3) eap: ERROR: Failed continuing EAP TLS (13) session. EAP sub-module failed (3) eap: Sending EAP Failure (code 4) ID 255 length 4 (3) eap: Failed in EAP select (3) [eap] = invalid (3) } # authenticate = invalid (3) Failed to authenticate the user (3) Using Post-Auth-Type Reject (3) # Executing group from file /etc/freeradius3/sites-enabled/default (3) Post-Auth-Type REJECT { (3) attr_filter.access_reject: EXPAND %{User-Name} (3) attr_filter.access_reject: --> user (3) attr_filter.access_reject: Matched entry DEFAULT at line 11 (3) [attr_filter.access_reject] = updated (3) [eap] = noop (3) policy remove_reply_message_if_eap { (3) if (&reply:EAP-Message && &reply:Reply-Message) { (3) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE (3) else { (3) [noop] = noop (3) } # else = noop (3) } # policy remove_reply_message_if_eap = noop (3) } # Post-Auth-Type REJECT = updated (3) Delaying response for 1.000000 seconds (0) Cleaning up request packet ID 22 with timestamp +589 due to cleanup_delay was reached (1) Cleaning up request packet ID 23 with timestamp +589 due to cleanup_delay was reached Waking up in 0.2 seconds. Waking up in 0.6 seconds. (3) Sending delayed response (3) Sent Access-Reject Id 25 from 127.0.0.1:1812 to 127.0.0.1:48027 length 44 (3) EAP-Message = 0x04ff0004 (3) Message-Authenticator = 0x00000000000000000000000000000000 Waking up in 3.9 seconds. I did update the eap file tls_min_version and tls_max_version to 1.3 Any help is highly appreciated. -Akhil

3 12

EAP-TLS extend logged lines
by Alexey D. Filimonov 19 Feb '25

19 Feb '25

Hello. Currently I have EAP-TLS auth. On successfull auth, it logs ``` Wed Feb 19 15:23:13 2025 : Auth: (9) Login OK: [anonymous-xxx] (from client name_of_client1 port 8 cli ee:ee:ee:ed:ae:ee) ``` I'd like to extend or replace this line with UPN from certiificate and other attributes. Where should I start from ?

2 3

Splitting Accounting Records into 30-Minute Files
by Erdal Emlik 19 Feb '25

19 Feb '25

Hi List, I know that with the Detail module, I can split the accounting records into hourly files. However, is there a way—perhaps using an expression in the filename or something similar—to further reduce this to 30-minute files? Best Regards,

2 1

Operator "!=" not allowed for LDAP group comparisons
by Rodrigo Antunes 17 Feb '25

17 Feb '25

Hi, how can I reject an ldap user if it is not member of a group by using the users file? I tried this: DEFAULT NAS-Identifier == "openVPN", LDAP-Group != "01-PL-Allow-VPN", Auth-Type := Reject But in the logs I see this: ERROR: files: Operator "!=" not allowed for LDAP group comparisons

3 3

Include all options from template into other blocks?
by Alexey D. Filimonov 17 Feb '25

17 Feb '25

Is there an ability to include _every_ option from `default_client` into `client name_of_client1` without moving them to separate file and with single directive? Something like that: # clients.conf default_client { secret = "TheDefaultClientSecret" require_message_authenticator = yes vlan_for_ssid-name = "50" } client name_of_client1 { $COPY ${.default_client} ipaddr = 10.1.1.1 } I understand there is ability to refer parameters one-by-one, like that: client name_of_client1 { ipaddr = 10.1.1.1 secret = ${..default_client.secret} require_message_authenticator = ${..default_client.require_message_authenticator} vlan_for_ssid-name = ${..default_client.vlan_for_ssid-name} } And there is ability to move all parameters to a separate file, like that # clients.conf client name_of_client1 { ipaddr = 10.1.1.1 $INCLUDE clients.defaults.conf } # clients.defaults.conf secret = "TheDefaultClientSecret" require_message_authenticator = yes vlan_for_ssid-name = "50" But interested in copying all set of parameters with single command.

2 3

Debian 12 libldap\GnuTLS when using NetworkRadius packages
by Alexey D. Filimonov 17 Feb '25

17 Feb '25

When installing freeRADIUS from NetworkRadius to Debian 12, I get this warning: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !! libldap is using GnuTLS, while FreeRADIUS is using OpenSSL !! There may be random issues with TLS connections due to this conflict. !! The server may also crash. !! See https://wiki.freeradius.org/modules/Rlm_ldap for more information. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Any suggestions where to get \ how to build libldap for debian linked to OpenSSL ?

3 3