- Freeradius-Users - lists.freeradius.org

"Failed to find "chap" as a module or policy".
by David le Roux 29 Mar '22

29 Mar '22

Hello again, I've been scratching my head with this one. As far as I can tell the config file in this area is no different to standard and mods-enabled/chap is present (unmodified). Mar 29 16:24:49 server freeradius[464918]: /etc/freeradius/3.0/radiusd.conf[2081]: Failed to find "chap" as a module or policy. Mar 29 16:24:49 server freeradius[464918]: /etc/freeradius/3.0/radiusd.conf[2081]: Please verify that the configuration exists in /etc/freeradius/3.0/mods-enabled/chap. Mar 29 16:24:49 server freeradius[464918]: /etc/freeradius/3.0/radiusd.conf[2081]: Failed to parse "chap" entry. Any ideas? David le Roux ________________________________ Miller Homes Limited Registered in Scotland - SC255429 2 Lochside View, Edinburgh Park, Edinburgh, EH12 9DH Disclaimer: The Information in this e-mail is confidential and for use by the addressee(s) only. It may also be privileged. If you are not the intended recipient please notify us immediately on +44 (0) 870 336 5000 and delete the message from your computer: you may not copy or forward it, or use or disclose its contents to any other person. We do not accept any liability or responsibility for: (1) changes made to this email after it was sent, or (2) viruses transmitted through this email or any attachment. Miller Homes Limited <https://www.millerhomes.co.uk>

2 1

DER format in TLS certificates
by Iñigo Vicente 29 Mar '22

29 Mar '22

Hi, Can I use Der format for certificates? When I try to use DER certificates I get this error on freeradius: (8) eap_tls: ERROR: (TLS) Alert write:fatal:decode error (8) eap_tls: ERROR: (TLS) Server : Error in error (8) eap_tls: ERROR: (TLS) Failed reading from OpenSSL: error:1417C087:SSL routines:tls_process_client_certificate:cert length mismatch (8) eap_tls: ERROR: (TLS) System call (I/O) error (-1) (8) eap_tls: ERROR: (TLS) EAP Receive handshake failed during operation (8) eap_tls: ERROR: [eaptls process] = fail (8) eap: ERROR: Failed continuing EAP TLS (13) session. EAP sub-module failed Thanks in advance! Iñigo

4 10

cache_eap
by Rouzier, James 28 Mar '22

28 Mar '22

To Whom it may concern, I am looking at how to use cache_eap. https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/raddb/mods-avai… However, it disabled in this commit. https://github.com/FreeRADIUS/freeradius-server/commit/875aa768ae457dbc540c… Is this still not working? James

2 3

(no subject)
by Ben Dronen 28 Mar '22

28 Mar '22

Hello all, Thank you all for your hard work in keeping FreeRadius excellent. I am currently running FreeRADIUS 3.0.20. I am looking to solve an issue with using a certificate purchased from GlobalSign with Android 11 clients. When connecting to WiFi, we select EAP-PEAP and MSCHAPv2, then as the domain we put the CA of the certificate we purchased, but when connecting, we get the "ERROR: TLS Alert read:fatal:unknown CA". I have seen some information on this error in previous threads (Alan DeKok said in a previous thread that "That's an alert from the client. It doesn't recognize the CA which signed the server certificate."). However, according to the list of official CA's found here: https://android.googlesource.com/platform/system/ca-certificates/+/master/f…, the GlobalSign Root CA is part of Android (filename b0f3e76e.0). I was able to get this working fine with a Let's Encrypt Certificate (using cert.pem as the certificate_file in mods-enabled/eap and fullchain.pem as the ca_file in mods-enabled/eap). However, this isn't working with the GlobalSign cert.pem and fullchain.pem (which I created manually with the certificate and CA chain). Does anybody have any insights? When making the fullchain.pem (shown below), I did it in this order: server, intermediate, then root, like the Let's Encrypt fullchain.pem was, to no avail. The reason we are using a GlobalSign certificate instead of the Let's Encrypt certificate is so iOS users don't have to re-accept a new certificate every 90 days, only once per year. The reason for needing a cert from a signed CA is so Android users don't have to import a CA to get on our 802.1x network. My insights on the certificate chain have come from this article: https://extremeportal.force.com/ExtrArticleDetail?an=000092023 Relevant output of freeradius -X (4) eap: Expiring EAP session with state 0x070e85d2040b9ce9 (4) eap: Finished EAP session with state 0x070e85d2040b9ce9 (4) eap: Previous EAP request found for state 0x070e85d2040b9ce9, released from the list (4) eap: Peer sent packet with method EAP PEAP (25) (4) eap: Calling submodule eap_peap to process data (4) eap_peap: Continuing EAP-TLS (4) eap_peap: Peer indicated complete TLS record size will be 7 bytes (4) eap_peap: Got complete TLS record (7 bytes) (4) eap_peap: [eaptls verify] = length included (4) eap_peap: <<< recv TLS 1.2 [length 0002] (4) eap_peap: ERROR: TLS Alert read:fatal:unknown CA (4) eap_peap: TLS_accept: Need to read more data: error (4) eap_peap: ERROR: Failed in __FUNCTION__ (SSL_read): error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca (4) eap_peap: TLS - In Handshake Phase (4) eap_peap: TLS - Application data. (4) eap_peap: ERROR: TLS failed during operation (4) eap_peap: ERROR: [eaptls process] = fail (4) eap: ERROR: Failed continuing EAP PEAP (25) session. EAP sub-module failed (4) eap: Sending EAP Failure (code 4) ID 5 length 4 (4) eap: Failed in EAP select My cert.pem: -----BEGIN CERTIFICATE----- MIIGmzCCBYOgAwIBAgIMajBJIuY5b8BN+l6mMA0GCSqGSIb3DQEBCwUAMFAxCzAJ BgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSYwJAYDVQQDEx1H bG9iYWxTaWduIFJTQSBPViBTU0wgQ0EgMjAxODAeFw0yMjAzMjExNDM2MjBaFw0y MzA0MjIxNDM2MTlaMHcxCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhNaWNoaWdhbjEY MBYGA1UEBxMPQmVycmllbiBTcHJpbmdzMRswGQYDVQQKExJBbmRyZXdzIFVuaXZl cnNpdHkxHjAcBgNVBAMTFWF1LXNlY3VyZS5hbmRyZXdzLmVkdTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAMoRZG3RnxHctqFla/2iY9DQbz5pJ9nMCmNK 3YCH6JI9W8hDgBxut9XuOn/AueFw7CwUII7Srbz4KorexY3Eiqv8SkcBKUBt1JBq UEmHE/8Yyrimd92H7FLA1uTlDGBzxTHdwxVeNqPuyAFI2KFTLu5VC5SQHw2Lv+mv ZGoXAwJWX5sMI3eg9900YQdRmE7kB2K3TUwLsceK+XUl33klyO2iLzawWuBW/9ot q1XBXlDa+yzQjSWjy3tqXBbpG1vR0wUTSg+SJfefxnmS7/2zxiw92twMssxlIBRR /RQy6F9hFqHCe5GlcScRtdLuXsB5ZkeGJ8O2lwyhysSBG7QD6YECAwEAAaOCA0ww ggNIMA4GA1UdDwEB/wQEAwIFoDCBjgYIKwYBBQUHAQEEgYEwfzBEBggrBgEFBQcw AoY4aHR0cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvZ3Nyc2FvdnNz bGNhMjAxOC5jcnQwNwYIKwYBBQUHMAGGK2h0dHA6Ly9vY3NwLmdsb2JhbHNpZ24u Y29tL2dzcnNhb3Zzc2xjYTIwMTgwVgYDVR0gBE8wTTBBBgkrBgEEAaAyARQwNDAy BggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9y eS8wCAYGZ4EMAQICMAkGA1UdEwQCMAAwPwYDVR0fBDgwNjA0oDKgMIYuaHR0cDov L2NybC5nbG9iYWxzaWduLmNvbS9nc3JzYW92c3NsY2EyMDE4LmNybDAgBgNVHREE GTAXghVhdS1zZWN1cmUuYW5kcmV3cy5lZHUwHQYDVR0lBBYwFAYIKwYBBQUHAwEG CCsGAQUFBwMCMB8GA1UdIwQYMBaAFPjvf/LNeGeo3m+PJI2I8YcDArPrMB0GA1Ud DgQWBBSuJYTQuH88gmK+ehPZAXGlCZc7VjCCAX4GCisGAQQB1nkCBAIEggFuBIIB agFoAHYAb1N2rDHwMRnYmQCkURX/dxUcEdkCwQApBo2yCJo32RMAAAF/rOhWdwAA BAMARzBFAiEA7oIQ46pAtSxjGcywhFYHCWPEI5PuAOB20HCx9jCjbhQCIAw/KCRe d63rnJIvNT0T96QhkVkPOCyNrEE37FrfbKvDAHYAVYHUwhaQNgFK6gubVzxT8MDk OHhwJQgXL6OqHQcT0wwAAAF/rOhWmQAABAMARzBFAiBp6kxFIdsObn7hKvLLA69a vBivCO35gFZgzjH0D+hfhQIhAMvcW4tKlTbX0JEINiqOnSW82eccD+ThfRl5XTtX ZIFGAHYArfe++nz/EMiLnT2cHj4YarRnKV3PsQwkyoWGNOvcgooAAAF/rOhWtQAA BAMARzBFAiEAgu8iuMwhI75ZZNKaR5kSN6YUI3RjbImfCSu5CeJeTboCIG9Vr+rc X/n7HcYNfBmAko55Wb/ZuS/fyBTB2xLFY3JFMA0GCSqGSIb3DQEBCwUAA4IBAQCW vXCgRBJ7c46coIF+ZbSRa9gb0kRC5L9s+/Y9J7O20zzbrqV03Gf+ylTYl+P39h0d l0pHYnoDCHXcXxdvQLtlJNKNrusk+pr4SAE3rgONnvibLHD+g77oNwLJgDkH4i7/ 6WGj7T7PWgO9H8YT4bPSl3tu94QSriSCgrf5aNUSCtpT5LqaL8DDBBdDvAS8fACC l9j4lHXGUP9W7cUujt8gY27+jOeSguY7YU5a1kM4uKjSqEsk09/ZdcAlKs5mXyUV 1zhoBPfkgElepbAzKqOdcVB+3u9cxaXRqEtgG7CZb4KZ4ADx52sWOVgNs36q4rTe DquX1hAsN3eajRspE+Rh -----END CERTIFICATE----- My fullchain.pem: -----BEGIN CERTIFICATE----- MIIGmzCCBYOgAwIBAgIMajBJIuY5b8BN+l6mMA0GCSqGSIb3DQEBCwUAMFAxCzAJ BgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSYwJAYDVQQDEx1H bG9iYWxTaWduIFJTQSBPViBTU0wgQ0EgMjAxODAeFw0yMjAzMjExNDM2MjBaFw0y MzA0MjIxNDM2MTlaMHcxCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhNaWNoaWdhbjEY MBYGA1UEBxMPQmVycmllbiBTcHJpbmdzMRswGQYDVQQKExJBbmRyZXdzIFVuaXZl cnNpdHkxHjAcBgNVBAMTFWF1LXNlY3VyZS5hbmRyZXdzLmVkdTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAMoRZG3RnxHctqFla/2iY9DQbz5pJ9nMCmNK 3YCH6JI9W8hDgBxut9XuOn/AueFw7CwUII7Srbz4KorexY3Eiqv8SkcBKUBt1JBq UEmHE/8Yyrimd92H7FLA1uTlDGBzxTHdwxVeNqPuyAFI2KFTLu5VC5SQHw2Lv+mv ZGoXAwJWX5sMI3eg9900YQdRmE7kB2K3TUwLsceK+XUl33klyO2iLzawWuBW/9ot q1XBXlDa+yzQjSWjy3tqXBbpG1vR0wUTSg+SJfefxnmS7/2zxiw92twMssxlIBRR /RQy6F9hFqHCe5GlcScRtdLuXsB5ZkeGJ8O2lwyhysSBG7QD6YECAwEAAaOCA0ww ggNIMA4GA1UdDwEB/wQEAwIFoDCBjgYIKwYBBQUHAQEEgYEwfzBEBggrBgEFBQcw AoY4aHR0cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvZ3Nyc2FvdnNz bGNhMjAxOC5jcnQwNwYIKwYBBQUHMAGGK2h0dHA6Ly9vY3NwLmdsb2JhbHNpZ24u Y29tL2dzcnNhb3Zzc2xjYTIwMTgwVgYDVR0gBE8wTTBBBgkrBgEEAaAyARQwNDAy BggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9y eS8wCAYGZ4EMAQICMAkGA1UdEwQCMAAwPwYDVR0fBDgwNjA0oDKgMIYuaHR0cDov L2NybC5nbG9iYWxzaWduLmNvbS9nc3JzYW92c3NsY2EyMDE4LmNybDAgBgNVHREE GTAXghVhdS1zZWN1cmUuYW5kcmV3cy5lZHUwHQYDVR0lBBYwFAYIKwYBBQUHAwEG CCsGAQUFBwMCMB8GA1UdIwQYMBaAFPjvf/LNeGeo3m+PJI2I8YcDArPrMB0GA1Ud DgQWBBSuJYTQuH88gmK+ehPZAXGlCZc7VjCCAX4GCisGAQQB1nkCBAIEggFuBIIB agFoAHYAb1N2rDHwMRnYmQCkURX/dxUcEdkCwQApBo2yCJo32RMAAAF/rOhWdwAA BAMARzBFAiEA7oIQ46pAtSxjGcywhFYHCWPEI5PuAOB20HCx9jCjbhQCIAw/KCRe d63rnJIvNT0T96QhkVkPOCyNrEE37FrfbKvDAHYAVYHUwhaQNgFK6gubVzxT8MDk OHhwJQgXL6OqHQcT0wwAAAF/rOhWmQAABAMARzBFAiBp6kxFIdsObn7hKvLLA69a vBivCO35gFZgzjH0D+hfhQIhAMvcW4tKlTbX0JEINiqOnSW82eccD+ThfRl5XTtX ZIFGAHYArfe++nz/EMiLnT2cHj4YarRnKV3PsQwkyoWGNOvcgooAAAF/rOhWtQAA BAMARzBFAiEAgu8iuMwhI75ZZNKaR5kSN6YUI3RjbImfCSu5CeJeTboCIG9Vr+rc X/n7HcYNfBmAko55Wb/ZuS/fyBTB2xLFY3JFMA0GCSqGSIb3DQEBCwUAA4IBAQCW vXCgRBJ7c46coIF+ZbSRa9gb0kRC5L9s+/Y9J7O20zzbrqV03Gf+ylTYl+P39h0d l0pHYnoDCHXcXxdvQLtlJNKNrusk+pr4SAE3rgONnvibLHD+g77oNwLJgDkH4i7/ 6WGj7T7PWgO9H8YT4bPSl3tu94QSriSCgrf5aNUSCtpT5LqaL8DDBBdDvAS8fACC l9j4lHXGUP9W7cUujt8gY27+jOeSguY7YU5a1kM4uKjSqEsk09/ZdcAlKs5mXyUV 1zhoBPfkgElepbAzKqOdcVB+3u9cxaXRqEtgG7CZb4KZ4ADx52sWOVgNs36q4rTe DquX1hAsN3eajRspE+Rh -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIEYDCCA0igAwIBAgILBAAAAAABL07hRQwwDQYJKoZIhvcNAQEFBQAwVzELMAkG A1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jv b3QgQ0ExGzAZBgNVBAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw0xMTA0MTMxMDAw MDBaFw0yMjA0MTMxMDAwMDBaMF0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9i YWxTaWduIG52LXNhMTMwMQYDVQQDEypHbG9iYWxTaWduIE9yZ2FuaXphdGlvbiBW YWxpZGF0aW9uIENBIC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDdNR3yIFQmGtDvpW+Bdllw3Of01AMkHyQOnSKf1Ccyeit87ovjYWI4F6+0S3qf ZyEcLZVUunm6tsTyDSF0F2d04rFkCJlgePtnwkv3J41vNnbPMYzl8QbX3FcOW6zu zi2rqqlwLwKGyLHQCAeV6irs0Z7kNlw7pja1Q4ur944+ABv/hVlrYgGNguhKujiz 4MP0bRmn6gXdhGfCZsckAnNate6kGdn8AM62pI3ffr1fsjqdhDFPyGMM5NgNUqN+ ARvUZ6UYKOsBp4I82Y4d5UcNuotZFKMfH0vq4idGhs6dOcRmQafiFSNrVkfB7cVT 5NSAH2v6gEaYsgmmD5W+ZoiTAgMBAAGjggElMIIBITAOBgNVHQ8BAf8EBAMCAQYw EgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQUXUayjcRLdBy77fVztjq3OI91 nn4wRwYDVR0gBEAwPjA8BgRVHSAAMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8vd3d3 Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDMGA1UdHwQsMCowKKAmoCSGImh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcm9vdC5jcmwwPQYIKwYBBQUHAQEEMTAv MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC5nbG9iYWxzaWduLmNvbS9yb290cjEw HwYDVR0jBBgwFoAUYHtmGkUNl8qJUC99BM00qP/8/UswDQYJKoZIhvcNAQEFBQAD ggEBABvgiADHBREc/6stSEJSzSBo53xBjcEnxSxZZ6CaNduzUKcbYumlO/q2IQen fPMOK25+Lk2TnLryhj5jiBDYW2FQEtuHrhm70t8ylgCoXtwtI7yw07VKoI5lkS/Z 9oL2dLLffCbvGSuXL+Ch7rkXIkg/pfcNYNUNUUflWP63n41edTzGQfDPgVRJEcYX pOBWYdw9P91nbHZF2krqrhqkYE/Ho9aqp9nNgSvBZnWygI/1h01fwlr1kMbawb30 hag8IyrhFHvBN91i0ZJsumB9iOQct+R2UTjEqUdOqCsukNK1OFHrwZyKarXMsh3o wFZUTKiL8IkyhtyTMr5NGvo1dbU= -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIDdTCCAl2gAwIBAgILBAAAAAABFUtaw5QwDQYJKoZIhvcNAQEFBQAwVzELMAkG A1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jv b3QgQ0ExGzAZBgNVBAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05ODA5MDExMjAw MDBaFw0yODAxMjgxMjAwMDBaMFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9i YWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxT aWduIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDaDuaZ jc6j40+Kfvvxi4Mla+pIH/EqsLmVEQS98GPR4mdmzxzdzxtIK+6NiY6arymAZavp xy0Sy6scTHAHoT0KMM0VjU/43dSMUBUc71DuxC73/OlS8pF94G3VNTCOXkNz8kHp 1Wrjsok6Vjk4bwY8iGlbKk3Fp1S4bInMm/k8yuX9ifUSPJJ4ltbcdG6TRGHRjcdG snUOhugZitVtbNV4FpWi6cgKOOvyJBNPc1STE4U6G7weNLWLBYy5d4ux2x8gkasJ U26Qzns3dLlwR5EiUWMWea6xrkEmCMgZK9FGqkjWZCrXgzT/LCrBbBlDSgeF59N8 9iFo7+ryUp9/k5DPAgMBAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8E BTADAQH/MB0GA1UdDgQWBBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0B AQUFAAOCAQEA1nPnfE920I2/7LqivjTFKDK1fPxsnCwrvQmeU79rXqoRSLblCKOz yj1hTdNGCbM+w6DjY1Ub8rrvrTnhQ7k4o+YviiY776BQVvnGCv04zcQLcFGUl5gE 38NflNUVyRRBnMRddWQVDf9VMOyGj/8N7yy5Y0b2qvzfvGn9LhJIZJrglfCm7ymP AbEVtQwdpf5pLGkkeB6zpxxxYu7KyJesF12KwvhHhm4qxFYxldBniYUr+WymXUad DKqC5JlR3XC321Y9YeRq4VzW9v493kHMB65jUr9TU/Qr6cf9tveCX4XSQRjbgbME HMUfpIBvFSDJ3gyICh3WZlXi/EjJKSZp4A== -----END CERTIFICATE----- Thank you for your assistance. Apologies if this is a stupid question, I have tried to solve this on my own but am currently at a roadblock*.*

3 2

Is there any way to get %{NAS-Port-Type} to use the number 19 rather than Wireless-IEEE 802.11?
by Lucian Kim 28 Mar '22

28 Mar '22

Hello? You want to use the NAS-Port-Type attribute for authentication. By the way, RFC tries to use the defined numeric value, but if you look at the log of FreeRADIUS, it is displayed in the form of a string. For example, NAS-Port-Type 19 is displayed as Wireless-IEEE 802.11. I want to use 19 for inquiry in the database. When I refer to %{NAS-Port-Type}, it is displayed as Wireless-IEEE 802.11. Is there any way to use 19? thank you.

2 2

Modifying incoming packets with unlang
by David le Roux 28 Mar '22

28 Mar '22

Hello, I am migrating from an old raddb instance and one of the changes is that freeradius no longer uses the attr_rewrite module and instead relies on unlang. We use this module to change the packet requests and I have scoured the documentation but have made no headway in translating the following two commands, especially in how to deal with packets. Could I get some pointers by any unlang experts, I'm really scratching my head and this is all new to me. Thanks ============================= attr_rewrite copyusertocertcn { attribute = Cert-CN new_attribute = yes searchfor = "" searchin = packet replacewith = "%{User-Name}" } attr_rewrite removehostportion { attribute = Cert-CN searchin = packet searchfor = "(host/)(.*)" replacewith = "%{2}" ignore_case = no new_attribute = no } ============================= Kind regards, David le Roux ________________________________ Miller Homes Limited Registered in Scotland - SC255429 2 Lochside View, Edinburgh Park, Edinburgh, EH12 9DH Disclaimer: The Information in this e-mail is confidential and for use by the addressee(s) only. It may also be privileged. If you are not the intended recipient please notify us immediately on +44 (0) 870 336 5000 and delete the message from your computer: you may not copy or forward it, or use or disclose its contents to any other person. We do not accept any liability or responsibility for: (1) changes made to this email after it was sent, or (2) viruses transmitted through this email or any attachment. Miller Homes Limited <https://www.millerhomes.co.uk>

2 2

Get EAP version and TLS method via radius attributes
by Ibaakee Ledum 25 Mar '22

25 Mar '22

Hello, I'm a newbie to freeradius so forgive my lack of knowledge. I use the rlm_python module during radius authentication / authorization and would like to know if during EAP authentication, attributes related to EAP can be fetched from the rlm_python module to determine the EAP method used and TLS version if possible. E.g we have functions like *authorize, authenticate, post_auth *which are called during a radius request for rlm_python and they all accept a vps argument containing a tuple of request attributes, e.t.c. Is it possible to fetch EAP method and TLS version from this vps argument ? Thanks

2 1

Problem with "Fragmented IP protocol"
by Luca Bertoncello 24 Mar '22

24 Mar '22

Hi again, As I wrote yesterday, we have an Access Point in one office, connected via OpenVPN to the main office. Freeradius runs on the main office. When trying to authenticate with EAP-TLS it does not works (APs in main office have no problem). With Wireshark I see the error: 13 0.480756 10.6.21.9 10.0.21.10 IPv4 1516 Fragmented IP protocol (proto=UDP 17, off=0, ID=a62d) The packet was fragmented, but seems to reach the server with Freeradius. Can someone help me to solve the problem? Thanks a lot Luca Bertoncello

1 0

Setting Framed-MTU Attribute
by Luca Bertoncello 24 Mar '22

24 Mar '22

Hi list! We have a Freeradius 3.0.17 from Debian Repositories to serve the WLAN-Enterprise authentication. It work(ed) wonderful. Now we have a second office, connected via OpenVPN. In this office, too, there are devices that need to connect to the WLAN. We use Unifi to manage our WLANs. The problem: if the device uses WPA2-Enteprise with password authentication it works via VPN, too. If the device uses a certificate, the authentication process does not work. With tcpdump I see: 7 0.326167 10.6.21.10 10.0.21.10 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=0, ID=ced8) I already searched in net and I think, I have to set the Framed-MTU attribute to a lesser value. Current it is 1400 (if I see other packets in the communication). Problem: I cannot find a way to set it... I already tried to add the attribute in mods-config/attr_filter/access_challenge and in the inner tunnel. Even is the attribute 1400... Can someone help me? Thanks Luca Bertoncello

4 13

Freeradius (packetfence) - Error binding to port for 127.0.0.1 port 18121
by P.Thirunavukkarasu 24 Mar '22

24 Mar '22

Hi all, The following is the debug output and the error I noticed in the freeradius *freeradius -X* radiusd: #### Opening IP addresses and Ports #### listen { type = "auth" ipaddr = 127.0.0.1 port = 18120 } listen { type = "auth" ipaddr = * port = 0 limit { max_connections = 16 lifetime = 0 idle_timeout = 30 } Failed binding to auth address * port 1812 bound to server default: Address already in use /etc/freeradius/sites-enabled/default[59]: Error binding to port for 0.0.0.0 port 1812 */usr/sbin/freeradius -d /usr/local/pf/raddb -n auth -fxx -l stdout* auth: #### Opening IP addresses and Ports #### listen { type = "status" virtual_server = "status" ipaddr = 127.0.0.1 port = 18121 Failed binding to status address 127.0.0.1 port 18121 bound to server status: Address already in use /usr/local/pf/raddb/auth.conf[7]: Error binding to port for 127.0.0.1 port 18121 Regards, Thirunavukkarasu

5 6