June 2025 - Freeradius-Users - lists.freeradius.org

Freeradius accounting 4294967296
by Julio Edel Salas Díaz 24 Jun '25

24 Jun '25

Hi, I'm reviewing the "accounting" module in my Freeradius, and in the "radacct" table, I notice that the value 4294967296 has been added to "acctinputoctets" and "acctoutputoctets" for some users, which is affecting the use of the "sqlcounter" module. Can anyone tell me how to fix this?: 1945915 2C3290C0D883AE5F 2cf8f5be595f748853b59cb68b1234ce juan.vinardell6AC6162C01022 Wireless-802.11 2025-06-2117:35:06.000 -0400 2025-06-21 17:41:48.000 -0400 2025-06-21 17:41:48.000 -0400 300 402 RADIUS CONNECT 54Mbps 802.11g CONNECT 54Mbps 802.11g 42949672964294967296

2 3

Handling prefix and suffix realms in the same server
by paul.moser＠bt.com 18 Jun '25

18 Jun '25

I have a radius server that until recently was handling a number of realms, some with a realm suffix, others with a realm prefix. To do this someone has in the past uncommented the IPASS realm module in the default server, and also added ignore_null = true in the IPASS realm module configuration. As we were ceasing support for a number of prefix realms I removed their explicit entries from proxy.conf and added a DEFAULT entry which mapped to a virtual server that basically sent back Access-Rejects and a bit of logging so we could track down client and tell then to re-configure their devices. This all worked for the ceased realms, however, we were surprised to also note a huge drop in traffic on one of the suffix realms. We have tracked down cause of the drop in traffic on our suffix realm to the fact that some of those usernames also have a '/' character in them. Previously when the FreeRadius IPASS realm module parsed those realms, whilst it appeared to find a prefix realm, it found no match in its configuration and so would fall through to letting the suffix module try, which would match and then successfully end up proxying the packet on. With a DEFAULT realm also configured when the IPASS module encounters a suffix realm username that also has a '/' in it then rather than falling through and letting the suffix module handle it it instead matches it against the DEFAULT realm and so ends up sending an Access-Reject back. I note that the FreeRadius default config only has the suffix realm configured in the default server - I suspect that maybe the general advice would be only use prefix or suffix realms not both, and if you use both expect such edge-case such issues - would that be a fair opinion? In the case I have I can resolve it by: * Either keeping in the realm entries for the realms we are ceasing, but map them to the new virtual server that rejects/logs, and no DEFAULT realm. * Or remove the mappings for the ceased prefix realms but also instead of adding a DEFAULT realm add a NULL realm that maps to the virtual server that rejects/logs so that the IPASS module won't match, and the suffix module won't match a realm so will return the NULL realm. However, I do have another radius server that also handles prefix and suffix realms, already has a DEFAULT and NULL realm configured and I'm now concerned that it may have similar issues that we've not noticed or could in the future as an unintended side effect of another seemingly innocent change we might make. In trying to figure out what was going on I've been through the server logs in debug, through our configuration and even through the rlm_realm.c code. As already mentioned we have ignore_null = true in our IPASS realm configuration, this doesn't seem to be mention in the latest documentation (although Google will throw up an old page that does mentions it), there use to be a reference to it as a comment in the default server but that was removed in commit d5d4ba6673cce86ba058583ce7e38fb53a4ddae8 with the commit message "the parameter ignore_null doesn't exist". Looking at the rlm_realm.c C code it is still there, as well as an ignore_default. Have these become undocumented as they are going to be removed, or just because of complexity/complications of using them (and use at your own risk if you fully understand the implications in your context)? With v4 on the horizon - I've taken a brief look at it and realm handling is clearly different - do I need to be thinking of getting to a point where a radius server only handles suffix or prefix realms or will v4 handle this, or does it make it simpler , or does it remain a complex problem (simply because it is a complex problem) to handle both reliably? Thanks, Paul

2 1

Re: Re: DHCP Broadcasts not seen by radiusd
by Hermann.Lauer＠uni-heidelberg.de 18 Jun '25

18 Jun '25

> On Jun 17, 2025, at 7:40 AM, Hermann.Lauer(a)uni-heidelberg.de wrote: > > freeradius is not seeing DHCP broadcast discover messages on the same > > subnet. ... > If you set 'broadcast = yes' in the configuration, it will accept broadcast packets. Which is set, but seems not to show up in the -X debug output. > That flag sets a socket option which tells the kernel to forward broadcast packets to FreeRADIUS. Found my error: ipv4addr = 0.0.0.0 or ipaddr = 0.0.0.0 needs to be set to recieve non subnet broadcasts. Thanks and greetings Hermann PS: "ss -f inet -a -e" helped to see this -- Administration/Zentrale Dienste, Interdiziplinaeres Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg IWR; INF 205; 69120 Heidelberg; Tel: (06221)54-14405 Fax: -14427 Email: Hermann.Lauer(a)iwr.uni-heidelberg.de

2 1

DHCP Broadcasts not seen by radiusd
by Hermann.Lauer＠uni-heidelberg.de 17 Jun '25

17 Jun '25

Hi, freeradius is not seeing DHCP broadcast discover messages on the same subnet. Wireshark shows the broadcasts arriving, so for some reasons the packets seems not being transmitted from the kernel to the radius server level. Permissions are set via setcap (if I remove those, it complains about them missing at startup): #getcap /usr/sbin/freeradius /usr/sbin/freeradius cap_net_bind_service,cap_net_broadcast,cap_net_admin=eip How can I debug that further on debian trixie? Thanks a lot and greetings Hermann $ /usr/sbin/freeradius -X FreeRADIUS Version 3.2.7 <lots of stuff omitted> radiusd: #### Loading Virtual Servers #### server { # from file /etc/freeradius/3.0/radiusd.conf } # server server dhcp { # from file /etc/freeradius/3.0/sites-enabled/dhcp # Loading dhcp DHCP-Discover {...} Compiling dhcp DHCP-Discover for attr DHCP-Message-Type # Loading dhcp DHCP-Request {...} Compiling dhcp DHCP-Request for attr DHCP-Message-Type # Loading dhcp DHCP-Decline {...} Compiling dhcp DHCP-Decline for attr DHCP-Message-Type # Loading dhcp DHCP-Inform {...} Compiling dhcp DHCP-Inform for attr DHCP-Message-Type # Loading dhcp DHCP-Release {...} Compiling dhcp DHCP-Release for attr DHCP-Message-Type # Loading dhcp DHCP-Lease-Query {...} Compiling dhcp DHCP-Lease-Query for attr DHCP-Message-Type } # server dhcp radiusd: #### Opening IP addresses and Ports #### listen { type = "dhcp" ipv4addr = 192.168.0.1 port = 67 performance { skip_duplicate_checks = no } src_ipaddr = 192.168.0.1 } Listening on dhcp interface eno4 address 192.168.0.1 port 67 bound to server dhcp Ready to process requests

2 1

Best OTP 2FA with Free Radius and AD
by Matthew Beechey 13 Jun '25

13 Jun '25

I have freeradius working with Activedirectory to authenticate users on a Fortinet Gateway. I'd like to add OTP so users can use Google Auth, Authy, Microsoft Authenticator or their favourite OTP software. What are people currently using and is there a recommendation for something on the Freeradius server? I've searched for options and getting a million answers only to find after going down the garden path there are issues with how codes are issued. Just after some tips on what people have used.

2 1

filter_inner_identity
by Rodrigo Prieto 11 Jun '25

11 Jun '25

Hi, I’m configuring TTLS+PAP and I have some doubts about how to hide users' identities. In the inner-tunnel file, I uncommented filter_inner_identity. I added the following to the /policy.d/filter file so that if the outer and inner usernames are the same, it rejects the request: if (&outer.request:User-Name == &User-Name) { update request { Module-Failure-Message = "Outer User-Name cannot be the same as inner User-Name" } reject } The configuration in the filter file rejects the request if the user doesn’t use the word “anon”, but if I use anonrprieto as the outer identity and rprieto as the inner identity, obviously it doesn’t reject it and the inner identity gets exposed. Is there any way to protect against this, or is it unnecessary? Alan, don’t scold me :) Thanks.

2 2

TLS Radsec
by Rodrigo Prieto 10 Jun '25

10 Jun '25

Hello, I'm using Radsecproxy and when I run it in debug mode, I see that it reconnects every 30 seconds. I tried changing idle_timeout, but the same thing keeps happening. Here's the debug log using TLS 1.3: Listening on auth+acct from client (192.168.122.188, 37511) -> (*, 2083, virtual-server=default) (0) (TLS) RADIUS/TLS - Initiating new session (0) (TLS) RADIUS/TLS - Setting verify mode to require certificate from client (0) (TLS) RADIUS/TLS - Handshake state - before SSL initialization (0) (TLS) RADIUS/TLS - Handshake state - Server before SSL initialization (0) (TLS) RADIUS/TLS - Handshake state - Server before SSL initialization (0) (TLS) RADIUS/TLS - recv TLS 1.3 Handshake, ClientHello (0) (TLS) RADIUS/TLS - Handshake state - Server SSLv3/TLS read client hello (0) (TLS) RADIUS/TLS - send TLS 1.3 Handshake, ServerHello (0) (TLS) RADIUS/TLS - Handshake state - Server SSLv3/TLS write server hello (0) (TLS) RADIUS/TLS - send TLS 1.3 ChangeCipherSpec (0) (TLS) RADIUS/TLS - Handshake state - Server SSLv3/TLS write change cipher spec (0) (TLS) RADIUS/TLS - send TLS 1.3 Handshake, EncryptedExtensions (0) (TLS) RADIUS/TLS - Handshake state - Server TLSv1.3 write encrypted extensions (0) (TLS) RADIUS/TLS - send TLS 1.3 Handshake, CertificateRequest (0) (TLS) RADIUS/TLS - Handshake state - Server SSLv3/TLS write certificate request (0) (TLS) RADIUS/TLS - send TLS 1.3 Handshake, Certificate (0) (TLS) RADIUS/TLS - Handshake state - Server SSLv3/TLS write certificate (0) (TLS) RADIUS/TLS - send TLS 1.3 Handshake, CertificateVerify (0) (TLS) RADIUS/TLS - Handshake state - Server TLSv1.3 write server certificate verify (0) (TLS) RADIUS/TLS - send TLS 1.3 Handshake, Finished (0) (TLS) RADIUS/TLS - Handshake state - Server SSLv3/TLS write finished (0) (TLS) RADIUS/TLS - Handshake state - Server TLSv1.3 early data (0) (TLS) RADIUS/TLS - Server : Need to read more data: TLSv1.3 early data (0) (TLS) RADIUS/TLS - In Handshake Phase (0) (TLS) RADIUS/TLS - Handshake state - Server TLSv1.3 early data (0) (TLS) RADIUS/TLS - recv TLS 1.3 Handshake, Certificate (0) (TLS) RADIUS/TLS - Creating attributes from 2 certificate in chain (0) TLS-Cert-Serial := "7903974cb1367854b0fb2ee672ff78c68211ba5e" (0) TLS-Cert-Expiration := "250726070714Z" (0) TLS-Cert-Valid-Since := "250527070714Z" (0) TLS-Cert-Subject := "/C=FR/ST=Radius/L=Somewhere/O=Example Inc./emailAddress=admin(a)example.org/CN=free.loli.local" (0) TLS-Cert-Issuer := "/C=FR/ST=Radius/L=Somewhere/O=Example Inc./emailAddress=admin(a)example.org/CN=free.loli.local" (0) TLS-Cert-Common-Name := "free.loli.local" (0) TLS-Cert-CRL-Distribution-Points += " http://www.example.org/example_ca.crl" (0) (TLS) RADIUS/TLS - Creating attributes from 1 certificate in chain (0) TLS-Client-Cert-Serial := "02" (0) TLS-Client-Cert-Expiration := "250726070721Z" (0) TLS-Client-Cert-Valid-Since := "250527070721Z" (0) TLS-Client-Cert-Subject := "/C=FR/ST=Radius/O=Example Inc./CN=lolito/emailAddress=userdsdsd(a)example.org" (0) TLS-Client-Cert-Issuer := "/C=FR/ST=Radius/L=Somewhere/O=Example Inc./emailAddress=admin(a)example.org/CN=free.loli.local" (0) TLS-Client-Cert-Common-Name := "lolito" (0) TLS-Client-Cert-CRL-Distribution-Points += " http://www.example.com/example_ca.crl" (0) TLS-Client-Cert-X509v3-Extended-Key-Usage += "TLS Web Client Authentication" (0) TLS-Client-Cert-X509v3-Subject-Key-Identifier += "FD:D3:42:C8:4A:F1:0C:65:A5:A3:B6:8E:2A:73:B0:FA:B2:0D:CF:CD" (0) TLS-Client-Cert-X509v3-Authority-Key-Identifier += "86:BC:40:4A:6E:B2:66:02:81:A5:75:19:DF:93:B8:AD:12:75:75:60" (0) TLS-Client-Cert-X509v3-Extended-Key-Usage-OID += "1.3.6.1.5.5.7.3.2" (0) (TLS) RADIUS/TLS - Handshake state - Server SSLv3/TLS read client certificate (0) (TLS) RADIUS/TLS - recv TLS 1.3 Handshake, CertificateVerify (0) (TLS) RADIUS/TLS - Handshake state - Server SSLv3/TLS read certificate verify (0) (TLS) RADIUS/TLS - recv TLS 1.3 Handshake, Finished (0) (TLS) RADIUS/TLS - Handshake state - Server SSLv3/TLS read finished (0) (TLS) RADIUS/TLS - Handshake state - SSL negotiation finished successfully (0) (TLS) RADIUS/TLS - Connection Established (0) TLS-Session-Cipher-Suite = "TLS_AES_256_GCM_SHA384" (0) TLS-Session-Version = "TLS 1.3" (0) (TLS) RADIUS/TLS - Application data. (0) (TLS) OpenSSL says that it needs to read more data. In the radsecproxy debug log, the following appears: Tue Jun 10 07:00:54 2025: createlistener: listening for udp on *:1812 Tue Jun 10 07:00:54 2025: tlsconnect: TLS connection to freeradius_tls (Server-Freeradius port 2083), subject emailAddress=admin(a)example.org,CN=Server-Freeradius,O=Example Inc.,ST=Radius,C=FR up Tue Jun 10 07:01:24 2025: sslreadtimeout: SSL: error:0A000126:SSL routines::unexpected eof while reading Tue Jun 10 07:01:24 2025: tlsclientrd: connection to server freeradius_tls lost Tue Jun 10 07:01:24 2025: tlsconnect: TLS connection to freeradius_tls (Server-Freeradius port 2083), subject emailAddress=admin(a)example.org,CN=Server-Freeradius,O=Example Inc.,ST=Radius,C=FR up Using TLS 1.2 also disconnects, the debug is the same except for this: (0) (TLS) OpenSSL says that it needs to read more data. Clients connecting to radsecproxy reach FreeRadius correctly and everything works normally. I wanted to know if this disconnection is normal or if I'm doing something wrong? I'm testing this to implement it later. I'm using Debian 12. radiusd: FreeRADIUS Version 3.2.7 (git #694a97ddd), for host x86_64-pc-linux-gnu FreeRADIUS Version 3.2.7 OpenSSL 3.0.16 11 Feb 2025 (Library: OpenSSL 3.0.16 11 Feb 2025) Thank you.

2 4

Minor updates coming in 3.2.8
by Alan DeKok 06 Jun '25

06 Jun '25

I've pushed changes to the v3.2.x branch: When there are syntax errors in unlang keywords, it now prints out a URL to the online documentation on freeradius.org <http://freeradius.org/>. This should help people better understand the correct syntax. The reject_delay parameter has been updated. Previous it always _added_ a delay. It now enforces a _minimum_ delay. For most people this change won't be noticeable. If the server replies in 10 milliseconds, a reject delay of 1s will still result in a ~1s delay. The change mainly affects systems which are already slow. i.e. if an SQL database takes 4 seconds to return, then an Access-Reject will be sent out immediately, because 4 seconds have already passed. If an SQL database takes 0.5s to reply, then the reject will be delayed a further 0.5s, which adds up to the configured "reject_delay = 1" I've also added a boolean flag "delay_proxy_rejects". This is off by default. If set, it will apply the reject_delay time to proxy replies, too. In most cases, a proxy should just pass packets straight through, as fast as possible. However, in some cases, the home server doesn't delay rejects (e.g. NPS). In that situation, it's useful for a proxy to delay the reject. Delaying rejects prevents a large class of DoS attacks and problems with misconfigured / broken NAS equipment. Alan DeKok.

2 1

Help with NTLM_AUTH and a Fortigate
by Matthew Beechey 04 Jun '25

04 Jun '25

I've installed Freeradius 3.0 - That was a default with APT-GET - Let me know if manually getting a newer version is essential. I'm using it in front of a Windows Server and a Fortigate Firewall. I have it talking to the server and joined to the domain. I can manually use NTLM_AUTH and it authenticates Windows users like a dream. With DEFAULT Auth-Type = ntlm_auth in files/authorize I can authenticate users with NTRadPing although I cannot without the DEFAULT.... entry. I cannot authenticate users from the radius settings on the Fortigate - They always fail. Looking at logging from Freeradius with -X i see this entry mschap: Found MS-CHAP attributes. Setting 'Auth-Type = mschap' When I do it with NTRadPing with the DEFAULT set to ntlm_auth I get this entry in the logging (0) Found Auth-Type = ntlm_auth So I'm picking something about the request from the Fortigate is setting it to MSCHAP (v1) and with NTRadPing its doing it with ntlm_auth What do I need to do here - disable MSCHAPv1 and if so how - Something else to force MSCHAP to use NTLM_AUTH Essentially I want to use Windows users for Fortinet VPN and next step is going to be adding 2 Factor authentication with Google, Authy or Microsoft - Hoping I can do it as a rolling code so any app will work? Any pointers here or advice would be good if you have some.

3 11

Fetching memberOf attribute
by Matvey Teplov 03 Jun '25

03 Jun '25

Hi Guys, I cannot get the ldap module to fetch a memberOf attribute from AD - it is not putting it as a filter parameter in the LDAP search packet. I need this list later to search through for port-authentication phase through the groups in session-state:LDAP-Group[*]'s to identify which ones are present and return a proper VSA. The LDAP configuration is as follows: ldap { server = 'abc.nomios.nl' identity = 'CN=ABC,OU=ABC,DC=nomios,DC=nl' password = '#######' base_dn = 'DC=nomios,DC=nl' user { base_dn = "${..base_dn}" filter = "(sAMAccountName=%{%{Stripped-User-Name}:-%{User-Name}})" scope = 'sub' access_attr = "memberOf" attribute { memberOf := 'session-state:LDAP-Group' } } # group { # base_dn = "${..base_dn}" # membership_attribute = 'memberOf' # } options { chase_referrals = no rebind = yes ldap_debug = 1 timeout = 10 timelimit = 3 net_timeout = 1 idle = 60 } tls { start_tls = no } update { session-state:LDAP-Group := "%{ldap:memberOf}" } } If I run manually ldap_search, then membership shows. Wireshark confirms that there is no attribute request in the ldap search packet present. Any help will be greatly appreciated! Best regards Matvey Teplov +31 62 705 12 73

3 12