- Freeradius-Users - lists.freeradius.org

Crafting a CHAP auth request
by Alan Batie 11 Feb '25

11 Feb '25

I'm trying to use radclient to test chap authentication, however it looks like the chap-password attribute is getting encrypted or something and not passed as specified. How should one do this? I'm trying to get a test working with freeradius 1.1.7 that I can use to validate a freeradius 3.2.5 installation... https://freeradius-users.freeradius.narkive.com/OdBT8CjP/ms-chap-authentica… tshark -V for a real, accepted, request: Radius Protocol Code: Access-Request (1) Packet identifier: 0x7c (124) Length: 175 Authenticator: D9FC93F9B090BAD032E0F15793F31AE6 Attribute Value Pairs AVP: l=6 t=Service-Type(6): Framed-User(2) Service-Type: Framed-User (2) AVP: l=6 t=Framed-Protocol(7): PPP(1) Framed-Protocol: PPP (1) AVP: l=6 t=NAS-Port(5): 15832385 NAS-Port: 15832385 AVP: l=6 t=NAS-Port-Type(61): Ethernet(15) NAS-Port-Type: Ethernet (15) AVP: l=7 t=User-Name(1): CPEV2 User-Name: CPEV2 AVP: l=19 t=Calling-Station-Id(31): <macaddr> Calling-Station-Id: <macaddr> AVP: l=10 t=Called-Station-Id(30): service1 Called-Station-Id: service1 AVP: l=15 t=NAS-Port-Id(87): bridge2-10.11 NAS-Port-Id: bridge2-10.11 AVP: l=10 t=Acct-Session-Id(44): 81e19440 Acct-Session-Id: 81e19440 AVP: l=18 t=CHAP-Challenge(60): 16C474F4671ABE2E03E2F199B170E22A CHAP-Challenge: 16C474F4671ABE2E03E2F199B170E22A AVP: l=19 t=CHAP-Password(3): 015223EA79AAE8B427798EC0FA5EC35FA9 CHAP-Password: 015223EA79AAE8B427798EC0FA5EC35FA9 AVP: l=9 t=NAS-Identifier(32): knox-gw NAS-Identifier: knox-gw AVP: l=6 t=NAS-IP-Address(4): 207.55.2.20 NAS-IP-Address: 207.55.2.20 (207.55.2.20) AVP: l=18 t=Message-Authenticator(80): 4605A791CA930685357F73A2B89D6197 Message-Authenticator: 4605A791CA930685357F73A2B89D6197 From that, I craft up this input to radclient: Service-Type = Framed-User Framed-Protocol = PPP NAS-Port-Type = Ethernet NAS-Port = 15832385 User-Name = CPEv2 Calling-Station-Id = <macaddr> Called-Station-Id = service1 NAS-Port-Id = bridge2-10.11 Acct-Session-Id = 81e19440 CHAP-Challenge = 0x16C474F4671ABE2E03E2F199B170E22A CHAP-Password = 0x015223EA79AAE8B427798EC0FA5EC35FA9 NAS-Identifier = knox-gw NAS-IP-Address = 207.55.2.20 Message-Authenticator = 0x4605A791CA930685357F73A2B89D6197 However, what gets sent is: Radius Protocol Code: Access-Request (1) Packet identifier: 0xfd (253) Length: 175 Authenticator: 68FC978374D1E2D4B190667E651488E5 Attribute Value Pairs AVP: l=6 t=Service-Type(6): Framed-User(2) Service-Type: Framed-User (2) AVP: l=6 t=Framed-Protocol(7): PPP(1) Framed-Protocol: PPP (1) AVP: l=6 t=NAS-Port-Type(61): Ethernet(15) NAS-Port-Type: Ethernet (15) AVP: l=6 t=NAS-Port(5): 15832385 NAS-Port: 15832385 AVP: l=7 t=User-Name(1): CPEv2 User-Name: CPEv2 AVP: l=19 t=Calling-Station-Id(31): <macaddr> Calling-Station-Id: <macaddr> AVP: l=10 t=Called-Station-Id(30): service1 Called-Station-Id: service1 AVP: l=15 t=NAS-Port-Id(87): bridge2-10.11 NAS-Port-Id: bridge2-10.11 AVP: l=10 t=Acct-Session-Id(44): 81e19440 Acct-Session-Id: 81e19440 AVP: l=18 t=CHAP-Challenge(60): 16C474F4671ABE2E03E2F199B170E22A CHAP-Challenge: 16C474F4671ABE2E03E2F199B170E22A AVP: l=19 t=CHAP-Password(3): FDB41FBAC26B503DBA63E94B8C667E928A CHAP-Password: FDB41FBAC26B503DBA63E94B8C667E928A AVP: l=9 t=NAS-Identifier(32): knox-gw NAS-Identifier: knox-gw AVP: l=6 t=NAS-IP-Address(4): 207.55.2.20 NAS-IP-Address: 207.55.2.20 (207.55.2.20) AVP: l=18 t=Message-Authenticator(80): D07850811C046CAD43B07082152D0050 Message-Authenticator: D07850811C046CAD43B07082152D0050

2 2

Help in understanding variable expansion
by Luca Cavana 11 Feb '25

11 Feb '25

Hello, this environment is used to perform (also) EAP-TLS, which is working fine. The supplicants in this environment are a mixture of Linux and Windows that all send the User-Name attribute in the form used by Windows, which is: host/UPPERCASE_HOSTNAME.lowercase.fqdn. To be able to match the certificate's Subject to the User-Name attribute I am using the following piece of unlang (in post-auth) which matches the full fqdn and compares it with the certificate subject with a case insensitive regular expression. cavanasystems_verify_tls_client_common_name { if (&User-Name =~ /^host\/([A-Z0-9]{13}.corp\.cavanasystems\.com)/) { update request { &Sanitized-Host-Name := "%{1}" } } if ((&User-Name !~ /^@/) && &TLS-Client-Cert-Common-Name && (&TLS-Client-Cert-Common-Name !~ /%{&Sanitized-Host-Name}/i)) { reject } } This works but I have to instruct the Linux supplicants to send their User-Name as Windows does, which I do not like. If I change my regular expression match using variable substitution while defaulting another variable, like this: /%{%{&Sanitized-Host-Name}:-%{&User-Name}}/i ... which I expect to firstly match the Sanitized-Host-Name (which will exist only if a Windows supplicant is trying to authenticate) and if that does not exist, match with the User-Name (which is sent "good" by a Linux client). The problem is that this is what actually happens: the following debug is from a Linux client mimicking the Windows behavior. (8) if ((&User-Name !~ /^@/) && &TLS-Client-Cert-Common-Name && (&TLS-Client-Cert-Common-Name !~ /%{%{&Sanitized-Host-Name}:-%{&User-Name}}/i)) { (8) EXPAND %{%{&Sanitized-Host-Name}:-%{&User-Name}} (8) --> ITMIL01CD0002\\.corp\\.cavanasystems\\.com (8) if ((&User-Name !~ /^@/) && &TLS-Client-Cert-Common-Name && (&TLS-Client-Cert-Common-Name !~ /%{%{&Sanitized-Host-Name}:-%{&User-Name}}/i)) -> TRUE (8) if ((&User-Name !~ /^@/) && &TLS-Client-Cert-Common-Name && (&TLS-Client-Cert-Common-Name !~ /%{%{&Sanitized-Host-Name}:-%{&User-Name}}/i)) { (8) [reject] = reject (8) } # if ((&User-Name !~ /^@/) && &TLS-Client-Cert-Common-Name && (&TLS-Client-Cert-Common-Name !~ /%{%{&Sanitized-Host-Name}:-%{&User-Name}}/i)) = reject (8) } # policy cavanasystems_verify_tls_client_common_name = reject I've enabled some debug and this is the state the AVPs are in: (8) Attributes matching "request:" (8) &request:User-Name = host/ITMIL01CD0002.corp.cavanasystems.com (8) &request:Sanitized-Host-Name := ITMIL01CD0002.corp.cavanasystems.com I don't understand why it looks like the server is escaping the dots "\\." while doing the EXPAND operation. Thank you very much, Luca Cavana

2 3

FreeRADIUS Not Storing Cache Data in Redis
by Luca Borruto 11 Feb '25

11 Feb '25

Hi everyone, We are currently facing an issue with FreeRADIUS where no cache entries are being created in Redis. We’ve tested the Redis connection, authentication, and database selection, but when we run KEYS * in Redis, it returns an empty array. When running FreeRADIUS in debug mode (radiusd -X), we do not see any Redis-related errors, yet the expected data is not found in Redis. I configured redis, cache, cache_tls and cache_eap modules for testing purpose, and it's still a bit confusing on which one to enable for production (we use only EAP-TLS with Radsec): *mods-enabled/redis:* redis { server = raddb-redis-master.radius.svc.cluster.local port = 6379 password = root } *mods-enabled/cache:* cache cache_redis { driver = "rlm_cache_redis" key = "%{control:State}" ttl = 43200 redis { server = raddb-redis-master.radius.svc.cluster.local port = 6379 password = root } update { &reply: += &reply: &control:State := &request:State } } *mods-enabled/cache_tls:* cache cache_tls_session { driver = rlm_cache_redis key = &Session-Id ttl = 43200 redis { server = raddb-redis-master.radius.svc.cluster.local port = 6379 password = root } update { &reply:TLS-Session-Data := &session-state:TLS-Session-Data } } *mods-enabled/cache_eap:* cache cache_eap { driver = rlm_cache_redis key = "%{control:State}" ttl = 43200 redis { server = raddb-redis-master.radius.svc.cluster.local port = 6379 password = root } update reply { &reply += &reply &control:State := &request:State } } Is there anything wrong with our configuration that could be preventing data from being stored in Redis? Any help would be greatly appreciated. Please let me know if any additional logs or details would be helpful. Best regards, Luca,

2 2

Configuring FreeRADIUS Behind Azure Load Balancer - Health Probe Issue
by Luca Borruto 10 Feb '25

10 Feb '25

Hello everyone, I am currently running FreeRADIUS v3.2.6 on K8S behind an Azure Load Balancer, serving RadSec (TLS on TCP 2083) for wifi EAP authentication. The load balancer is configured with a TCP health probe on port 2083 to verify the service’s availability (that's the way Azure LB works), the issue is that FreeRADIUS does not seem to accept these health probe requests. In the logs, I see messages like: Ignoring request to auth+acct proto tcp address * port 2083 (TLS) bound to server default from unknown client 10.0.2.4 port 3286 proto tcp The health probe originates from internal ALB IPs (e.g., 10.0.2.4, 10.0.2.33). FreeRADIUS rejects them as unknown clients and as a result, the load balancer marks the service as unhealthy and so, the traffic is not achieved to the freeradius pods. I am looking for guidance on the recommended way to configure FreeRADIUS to work behind an Azure Load Balancer: What is the best practice for handling this scenario? Any official recommendations or insights from the community would be greatly appreciated. Best regards, Luca Borruto IT System Administrator

3 6

mschap
by Alan Batie 08 Feb '25

08 Feb '25

I'm migrating an outdated system from centos 5/freeradius 1.1.7 to ubuntu 24/freeradius 3.2.5; it authenticates ppp connections via mschap by mac address with an sql procedure call. It doesn't look like there's anything to configure in mschap, the old system has all the mschap stuff commented out by default and so does the new system, but mschap is failing and it looks like it's not even getting to the sql part. It really just needs to ignore the mschap since the only part of it getting used is one of a few static usernames. I can send the full debug output privately if need be... It does work if you're using pap instead of chap, so the sql part works... (0) Received Access-Request Id 176 from 10.65.23.69:47717 to 10.67.10.137:1812 length 294 (0) Message-Authenticator = 0xcc69da5fbbc2a69a88a5e18907ebcc29 (0) Service-Type = Framed-User (0) Framed-Protocol = PPP (0) NAS-Port-Type = Ethernet (0) User-Name = "CPEv2" (0) Calling-Station-Id = "64:D1:54:7A:B1:F4" (0) Calling-Station-Id = "tarana-service" (0) NAS-Port-Id = "vlan2000-tarana" (0) Acct-Session-Id = "81f01557" (0) MS-CHAP-Challenge = 0x3131366139653232316662366161376332313437343231373735346236613135 (0) MS-CHAP2-Response = 0x30313030363236663563643935326431373930373966376465333139303966356465323230303030303030303030303030303030326261653431646 530306330366137666137376464356132313063313662623037613235363063623563333838373264 (0) NAS-Identifier = "admin03" (0) NAS-IP-Address = 207.55.16.41 (0) NAS-Port = 15762707 (0) # Executing section authorize from file /etc/freeradius/3.0/sites-enabled/peak (0) authorize { (0) [preprocess] = ok (0) auth_log: EXPAND /var/log/freeradius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/auth-detail-%Y%m%d (0) auth_log: --> /var/log/freeradius/radacct/10.65.23.69/auth-detail-20250206 (0) auth_log: /var/log/freeradius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/auth-detail-%Y%m%d expands to /var/log/freeradius/radacct/10.65.23.69/auth-detail-20250206 (0) auth_log: EXPAND %t (0) auth_log: --> Thu Feb 6 15:44:52 2025 (0) [auth_log] = ok (0) [chap] = noop (0) mschap: Found MS-CHAP attributes. Setting 'Auth-Type = mschap' (0) [mschap] = fail (0) } # authorize = fail (0) Invalid user: [CPEv2] (from client admin01 port 15762707 cli 64:D1:54:7A:B1:F4) (0) Using Post-Auth-Type Reject (0) # Executing group from file /etc/freeradius/3.0/sites-enabled/peak (0) Post-Auth-Type REJECT { (0) sql: EXPAND .query (0) sql: --> .query (0) sql: WARNING: No such configuration item .query (0) [sql] = noop (0) attr_filter.access_reject: EXPAND %{User-Name} (0) attr_filter.access_reject: --> CPEv2

2 5

Seeking assistance with eap_peap error log
by Joseph Repuyan 31 Jan '25

31 Jan '25

Hello, Good day to everyone. We have a wireless setup where the SSID password is updated every day. FreeRADIUS is used for authentication and some automation behind to update the password and store them to an SQL database. Mobile phones can successfully authenticate using the password for the day, but laptops cannot. The client claims both mac and windows laptops cannot connect but I only have logs of the windows machine attempting to authenticate. Attached are the logs. Near the bottom of the logs, I found these errors. From the looks of it, the client itself is complaining about the TLS exchange, but I'm lost as to what to check next. I cannot replicate the issue with my windows laptop using the same FreeRADIUS server (but using different a access point). (7) eap_peap: (TLS) EAP Peer says that the final record size will be 31 bytes (7) eap_peap: (TLS) EAP Got all data (31 bytes) (7) eap_peap: (TLS) PEAP - recv TLS 1.2 Alert, fatal access_denied (7) eap_peap: (TLS) PEAP - The client is informing us that there is a failure inside the TLS protocol exchange. (7) eap_peap: ERROR: (TLS) PEAP - Alert read:fatal:access denied (7) eap_peap: ERROR: (TLS) Error in fragmentation logic - code 1 (7) eap_peap: ERROR: (TLS) Failed reading application data from OpenSSL: error:0A000419:SSL routines::tlsv1 alert access denied (7) eap_peap: ERROR: [eaptls process] = fail (7) eap: ERROR: Failed continuing EAP PEAP (25) session. EAP sub-module failed (7) eap: Sending EAP Failure (code 4) ID 88 length 4 (7) eap: Failed in EAP select (7) [eap] = invalid (7) } # authenticate = invalid Regards, Joseph [cid:ea68704a-6679-482d-add8-dada5d5730a3] Joseph Repuyan Technical Consultant [cid:3c9afbd0-df84-456b-8360-722ef2e2b1cd]<https://www.linkedin.com/company/cloud4x/> [cid:79c2a19c-09f3-44f7-9739-da337b2450e7] <https://www.facebook.com/user_name_here> [cid:f67cdc37-ab87-4e28-82f3-f236945d4c23] <https://www.youtube.com/@Cloud4x-Australia> [banners-01.png] 1800 325 683 [banners-02.png] www.cloud4x.com.au<https://cloud4x.com.au/> [banners-03.png] Sydney Corporate Park, Level 4 184 Bourke Road, Alexandria, NSW 2015 [cloud4x-01.png]<https://cloud4x.com.au/documentation/> [cloud4x-02.png]<https://www.crn.com.au/news/announcing-the-2024-crn-impact-award-winners-61…>

2 3

Version 3.2.7 has been released
by Matthew Newton 31 Jan '25

31 Jan '25

We have released FreeRADIUS version 3.2.7 today. Some highlights in this release: - Easier configuration of TEAP - Configurable behaviour for "return" in policies and groups - see "unlang" in radiusd.conf - A new "python_path_mode" in rlm_python3 to configure how the python_path option is used. - Updates for RADIUS/TLS and more configuration options. Note that python2 and rlm_couchbase have been removed from the Alpine Docker images as the base OS has been updated and no longer supports Python 2 or Couchbase 2. Full information is in doc/ChangeLog. Download from the normal places: https://freeradius.org/releases/ https://freeradius.org/ftp/pub/freeradius/ https://github.com/FreeRADIUS/freeradius-server/releases/tag/release_3_2_7 Packages are available from InkBridge Networks for common Linux distributions as usual: https://packages.inkbridgenetworks.com/ and Docker images have been refreshed on Dockerhub: https://hub.docker.com/r/freeradius/freeradius-server -- Matthew

2 1

We have released version 3.2.7
by Alan DeKok 31 Jan '25

31 Jan '25

Release notes below. Note that we have updated TEAP, and are interoperable with Microsoft. However, there are open issues with the TEAP standard which are being worked through the IETF. As such, TEAP may or may not work outside of the "Microsoft - FreeRADIUS" ecosystem. I would suggest that people wait before doing wide-spread deployments for TEAP. Configuration changes • The dpsk module now supports dynamic expansion of the filename parameter. • radiusd.conf now contains an unlang section, which controls new behavior for the return statement. • New configuration parameters for TEAP which makes it much easier to configure. See the teap section of the eap module. • Change idle timeout for incoming radsec connections, to better match behavior of radsecproxy. • python2 and rlm_couchbase are no longer available in the alpine docker image. • utmp files are becoming obsolete due to 32-bit time. unix/radwtmp have been commented out in the default config and radlast is no longer installed if last is not present on the system. Feature improvements • Print MD5 hash of the configuration files in debug mode. This helps people track configuration changes. • Add support for IPv6 to "abinary" type. The fields are the same as for "ip", but use "ipv6", and IPv6 formatted addresses. • Update radclient to make it clear that Message-Authenticator is added to all Access-Request packets, even if the input file does not contain it. • Add support for Subject AltName URI. Closes #5450. • Add python_path_mode option to python3 module. • Relax checks on OpenSSL minor versions for OpenSSL 3.x. • Add API for deleting dynamic home servers. • Set SO_KEEPALIVE on outbound sockets, so firewalls are less likly to close TCP connections. • Allow querying of statistics when home_server has src_ipaddr set. See FreeRADIUS-Stats-Server-Src-IP-Address. Fixes #5483 • Update dictionary "man" page. Fixes #4346. • Change jlibtool to use --show-config, to avoid conflicts with clang --config. Fixes #5442. • RADIUS/TLS clients now support a tls subsection. For connections from this client, this section is used in preference to the "listen" TLS settings. This allows a server to easily present different identities to different clients. • RADIUS/TLS has been updated for TLS-PSK and TLS 1.3. Tested with radsecproxy. Bug fixes • For EAP-TLS, send TLS start without a length field. Some clients refuse to do EAP-TLS when this field exists. • Avoid blocking TLS sockets on corner cases during session setup. • Update home server stats. • Correct error message about untrusted certs. Fixes #5466. • Use PyEval_RestoreThread to swap to main thread. Fixes #5111 • Don't run Python detach function on config check. • Fix a number of issues with TLS connections and check_client_connections = yes. • Be more careful about managing the incoming queue when databases block the server. The server will still be unable to make progress, but it should crash less. Whether or not this is a good thing is unknown. • Better handler single-character expansions. Fixes #2216. • Correct calculation of EAP length in pre-proxy. Fixes #5486. • Don't segfault when using detail listeners. Fixes #5485 • Add build check for Couchbase v2, rlm_couchbase won't build on v3.

1 0

Unable to use freeradius 3.0.26 with openssl 3.0
by Amit P 31 Jan '25

31 Jan '25

Hi, I am using Freeradius version 3.0.26 for a basic authentication, My system is upgraded from Openssl 1.0.2 to 3.0.4 version and after this the authentication is failing because server is rejecting the incoming request with following message. Dropping packet without response because of error: Received packet from 10.0.0.1 with invalid Message-Authenticator! (Shared secret is incorrect.) This must be happening, because MD5 is deprecated in openssl3.0 which is used by Freeradius for calculating Message-Authenticator attribute. I could see in release notes of 3.0.26, openssl 3.0 and tls1.3 support is added. i need help with the below line from release notes. *Add configure-time FIPS workaround to use internal MD4/MD5 implementations when disabled in OpenSSL.* I believe this workaround is the solution to my problem, can you please help me in what exactly needs to be done for this workaround. Thanks & Regards, Amit

4 7

Message-Authenticator in Access-Challenge and Access-Accept
by FreeRAD 30 Jan '25

30 Jan '25

In Access-Requests I can see that the Message-Authenticator is set to a randomly generated string which I would expect. However in the Access-Challenge and Access-Accept packets it is just set to all 0s (e.g. 0x0000...). What could the reason be for a random string not being generated for the replies from the server to the NAS? I added the below in response to the BlastRADIUS vulnerability notification on the FreeRADIUS but I was under the impression that FreeRADIUS should still be generating it's own string based off of HMAC and shared secret etc. * if (!EAP-Message) { update reply { Message-Authenticator := 0x00 } }*

2 2