- Freeradius-Users - lists.freeradius.org

New vendor dictionary files - proper process to submit ?
by BuzzSaw Code 27 Jun '25

27 Jun '25

We found that F5 has updated their dictionary at the end of 2024 for some of their newest devices. What is the proper way to provide this so it can be added to future FreeRADIUS releases ? Reference - https://my.f5.com/manage/s/article/K14324 - A pull request on Github with the diff ? - An issue on Github attaching the updated dictionary ? - Have the vendor follow one of the above options so it comes direct from them ? - Something else ?

2 1

Problem with 802.1X and EAP-PEAP configuration
by Peter Sprenger 27 Jun '25

27 Jun '25

Hi, I have problem with 802.1X and after some time I am really desperated: - I am writing an Embedded Ansi C client that already supports EAP-TLS, EAP-TTLS PAP and EAP-TTLS CHAP. Now I thought EAP-PEAP would not be so hard. But with the FreeRadius config I cannot get the outer TLS-tunnel running. The TLS 1.2 connection gets rejected from my SSL library "ASN parsing error, invalid input". For EAP-TLS and EAP-TTLS I have no problem with TLS 1.2 and TLS 1.3 connections. - I tried to work with eapol_test and there is the same picture: EAP-TLS, EAP-TTLS PAP and EAP-TTLS CHAP are working, but for EAP-PEAP the outer TLS connection gets refused. - From ChatGPT I got the info, that TLS 1.3 may cause problems to EAP-PEAP. So I have restricted the client and the FreeRadius server to TLS 1.2. No success. Any help or idea what be very appreciated! Best Regards, Peter

2 1

Unlang policy to remove duplicate attributes from reply?
by tach yon 25 Jun '25

25 Jun '25

Hello, I've spent many hours searching the docs, examples, list posts, etc, plus AI generators - testing as many permutations I can think of - trying to find the correct syntax and method to do this with Unlang, but nothing seems to work 🙁 I'll try to explain in sudo-code what I mean: if (number of Framed-IP-Address attributes > 1) { update control { # Save the first Framed-IP-Address to a temporary String (because I read ipaddr type isn't available). &Tmp-String-0 := &reply:Framed-IP-Address[0] } update reply { # Remove all Framed-IP-Address entries currently in the reply. &Framed-IP-Address !* ANY # Re-create Framed-IP-Address with the first value we saved temporarily. # Cast as ipaddr because Framed-IP-Address needs that data type. &Framed-IP-Address := (ipaddr) &control:Tmp-String-0 } } Everything I've tried is either invalid syntax, or a comma is expected after the cast statement, or freeradius cannot resolve to IP address, or it just doesn't work. It's starting to drive me crazy 🙁 If anyone could please help me understand what I'm doing wrong, it would be very much appreciated. Thank you in advance for your time and consideration!

3 4

Freeradius docker
by Kat 25 Jun '25

25 Jun '25

Gday, I am new to Freeradius, radius, WPA Enterprise, EAP-TLS, etc. So I created a Docker container with Freeradius (https://hub.docker.com/r/freeradius/freeradius-server/) and I was looking at this tutorial: https://www.freeradius.org/documentation/freeradius-server/4.0.0/tutorials/… I do note that the tutorial appears to be listed for FreeRadius 4 BUT the page itself says that it is not yet updated for 4. So it means it applies to version 3??? In that tutorial it refers to three files, ( rlm_eap.so, but also rlm_tls_md5.so and rlm_eap_tls.so). I cannot find rlm_tls_md5.so in the Docker container. Does this mean that the docker container as is cannot run WPA-3 EAP-TLS Enterprise? if not, is there something I can do to change that? Can I add files or do I need to download and build freeradius in a docker container to make it work? Extra information in case it is needed: What you are trying to do: We are trying to get a WPA-3 Enterprise testing environment up and running and we are mostly using what we already have. We have a Unifi Wireless Access Point, and running UniFi Network Controller on a Synology NAS through a Docker environment in Portainer. FreeRadius is also running in a Docker container in that same Portainer. why you are trying to do it: I did originally try Synology Radius and did get that working BUT that doesn't support EAP-TLS which is what we are looking for here. And that is why I have Switched to FreeRadius which should support EAP-TLS but now I am unsure if the Free radius image from Freeradius does support EAP-TLS. what you expect the server to do: Run EAP-TLS for WPA-3 Enterprise. Best regards, Kat

2 1

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