You need to be very careful running a RADIUS server in Azure if you're using RADIUS/UDP. Azure has a network security feature on by default that drops fragmented UDP packets that arrive out of order. This negatively impacts RADIUS/UDP traffic. To give you an example, at least 20% of EAP-TLS auth attempts were failing for us in the cert auth phase due to this issue. Azure support can turn on the 'enable-udp-fragment-reordering' feature by request after providing packet captures and use case info etc. They will also only turn it on in a brand new subscription that's dedicated to running VMs that require this feature. After we did this, our auth success rate increased to 100%. Another thing to be wary of is setting 'tls_max_version' to 1.3. Windows 11 supports TLS 1.3 by default for EAP-TLS etc but does not yet support session resumption when using this protocol (see https://learn.microsoft.com/en-us/windows-server/networking/technologies/ext...). It's worth dropping the Max version to 1.2.
Wow, thanks for this! I couldn’t find any information about this online. I don’t think getting a new subscription is an option for us. I read somewhere that we can authorize TCP for RADIUS, right? If that’s not the case, I should consider trying another provider (GCP?) or setting up something on-premise, but that would limit the ability to connect other cities to this RADIUS server. Thanks for the answer! On Wed 18 Sep 2024 at 06:50, George Benjin <george.benjin@gmail.com> wrote:
You need to be very careful running a RADIUS server in Azure if you're using RADIUS/UDP.
Azure has a network security feature on by default that drops fragmented UDP packets that arrive out of order. This negatively impacts RADIUS/UDP traffic.
To give you an example, at least 20% of EAP-TLS auth attempts were failing for us in the cert auth phase due to this issue.
Azure support can turn on the 'enable-udp-fragment-reordering' feature by request after providing packet captures and use case info etc. They will also only turn it on in a brand new subscription that's dedicated to running VMs that require this feature. After we did this, our auth success rate increased to 100%.
Another thing to be wary of is setting 'tls_max_version' to 1.3. Windows 11 supports TLS 1.3 by default for EAP-TLS etc but does not yet support session resumption when using this protocol (see
https://learn.microsoft.com/en-us/windows-server/networking/technologies/ext... ). It's worth dropping the Max version to 1.2. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Sep 18, 2024, at 12:49 AM, George Benjin <george.benjin@gmail.com> wrote:
You need to be very careful running a RADIUS server in Azure if you're using RADIUS/UDP.
Azure has a network security feature on by default that drops fragmented UDP packets that arrive out of order. This negatively impacts RADIUS/UDP traffic.
Yes, that's a serious issue. The solution would be to use RADIUS/TLS.
Another thing to be wary of is setting 'tls_max_version' to 1.3. Windows 11 supports TLS 1.3 by default for EAP-TLS etc but does not yet support session resumption when using this protocol (see https://learn.microsoft.com/en-us/windows-server/networking/technologies/ext...). It's worth dropping the Max version to 1.2.
I had discussions with Microsoft a year or so about this. They were very happy to tell me that they had decided to not implement session resumption for TLS 1.3. They were not happy when I explained it was 100% necessary for many environments. A year later, "yeah, we'll fix it eventually". That's not useful. Alan DeKok.
Azure has a network security feature on by default that drops fragmented UDP packets that arrive out of order. This negatively impacts RADIUS/UDP traffic.
To give you an example, at least 20% of EAP-TLS auth attempts were failing for us in the cert auth phase due to this issue.
Azure support can turn on the 'enable-udp-fragment-reordering' feature by request after providing packet captures and use case info etc. They will also only turn it on in a brand new subscription that's dedicated to running VMs that require this feature. After we did this, our auth success rate increased to 100%.
We had this issue years ago and after several meetings, mails, capture analysis the support just blamed FreeRADIUS…
On Sep 19, 2024, at 1:51 AM, nabble@felix.world wrote:
We had this issue years ago and after several meetings, mails, capture analysis the support just blamed FreeRADIUS…
If it helps, maybe email me off-list. I'm usually happy to join calls where I can pull rank on the vendor. Vendor: FreeRADIUS Open Source, it's terrible. We're a billion dollar company, and filled with geniuses. Our product is perfect! Alan: Hi! I've been doing RADIUS since 1997. When did you start your IT career? Oh, I've also written most of the RADIUS standards. And if I see that your product does things I don't like, I'll just update the next rev of the standards to forbid it. At which point your product will be official non-compliant with the RFCs. And your customers will be pointing this out during sales calls. Have a nice day! Vendor: Uh... I guess we'll fix it then. I've had these conversations many times. Where facts, logic, and reason don't work, pulling rank generally works. Alan DeKok.
For the update, I’ve set up RadSec and it’s working perfectly now! Thanks y’all for the help! Luca, On Thu 19 Sep 2024 at 13:34, Alan DeKok <aland@deployingradius.com> wrote:
On Sep 19, 2024, at 1:51 AM, nabble@felix.world wrote:
We had this issue years ago and after several meetings, mails, capture analysis the support just blamed FreeRADIUS…
If it helps, maybe email me off-list. I'm usually happy to join calls where I can pull rank on the vendor.
Vendor: FreeRADIUS Open Source, it's terrible. We're a billion dollar company, and filled with geniuses. Our product is perfect!
Alan: Hi! I've been doing RADIUS since 1997. When did you start your IT career? Oh, I've also written most of the RADIUS standards. And if I see that your product does things I don't like, I'll just update the next rev of the standards to forbid it. At which point your product will be official non-compliant with the RFCs. And your customers will be pointing this out during sales calls. Have a nice day!
Vendor: Uh... I guess we'll fix it then.
I've had these conversations many times.
Where facts, logic, and reason don't work, pulling rank generally works.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
That's great news Luca. Happy to help. Thanks for the offer to pull rank, Alan - we'll keep that in mind! Cheers On Thu, 19 Sept 2024 at 23:38, Luca Borruto via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
For the update, I’ve set up RadSec and it’s working perfectly now! Thanks y’all for the help!
Luca,
On Thu 19 Sep 2024 at 13:34, Alan DeKok <aland@deployingradius.com> wrote:
On Sep 19, 2024, at 1:51 AM, nabble@felix.world wrote:
We had this issue years ago and after several meetings, mails, capture analysis the support just blamed FreeRADIUS…
If it helps, maybe email me off-list. I'm usually happy to join calls where I can pull rank on the vendor.
Vendor: FreeRADIUS Open Source, it's terrible. We're a billion dollar company, and filled with geniuses. Our product is perfect!
Alan: Hi! I've been doing RADIUS since 1997. When did you start your IT career? Oh, I've also written most of the RADIUS standards. And if I see that your product does things I don't like, I'll just update the next rev of the standards to forbid it. At which point your product will be official non-compliant with the RFCs. And your customers will be pointing this out during sales calls. Have a nice day!
Vendor: Uh... I guess we'll fix it then.
I've had these conversations many times.
Where facts, logic, and reason don't work, pulling rank generally works.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi (again) everyone, This morning I ran into an issue where iOS devices are unable to authenticate via RadSec (RADIUS over TLS). Other devices, including Windows, macOS, and Android, work perfectly fine. Here are the key details: - No Intermediate Certificates: We are only using our root CA for both our internal network and the Meraki-generated certificate for RadSec. There is no intermediate CA in place. - Configuration: FreeRADIUS is configured with `ca_dir`, as I need to add both our custom Root CA and the Meraki-generated CA (from the APs) to the trusted list. Only iOS devices seem to have this issue, all other devices (Windows, macOS, and Android) authenticate without any problems. Here’s a snippet of the logs from an iOS device trying to authenticate: ``` Certificate chain - 1 intermediate CA cert(s) untrusted To forbid these certificates see 'reject_unknown_intermediate_ca' (TLS) untrusted certificate with depth [1] subject name /DC=com/DC=redacted/CN=redacted-CA (TLS) untrusted certificate with depth [0] subject name /CN=FVFJH7381WFY ... (4) eap_tls: (TLS) TLS - recv TLS 1.2 Alert, fatal certificate_unknown (4) eap_tls: (TLS) TLS - The client is informing us that it does not recognize the server certificate. (4) eap_tls: ERROR: (TLS) TLS - Alert read:fatal:certificate unknown (4) eap_tls: ERROR: (TLS) Failed reading from OpenSSL: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown (4) eap_tls: ERROR: (TLS) Cannot continue, as the peer is misbehaving. (4) eap_tls: ERROR: [eaptls process] = fail (4) eap: ERROR: Failed continuing EAP TLS (13) session. EAP sub-module failed (4) eap: Sending EAP Failure (code 4) ID 39 length 4 (4) eap: Failed in EAP select ``` It seems like iOS is rejecting the certificate during the handshake, despite the configuration working fine on other platforms. Has anyone else experienced this issue with iOS and RadSec or can offer advice on how to resolve this? Thanks! Le ven. 20 sept. 2024 à 04:37, George Benjin <george.benjin@gmail.com> a écrit :
That's great news Luca. Happy to help.
Thanks for the offer to pull rank, Alan - we'll keep that in mind!
Cheers
On Thu, 19 Sept 2024 at 23:38, Luca Borruto via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
For the update, I’ve set up RadSec and it’s working perfectly now! Thanks y’all for the help!
Luca,
On Thu 19 Sep 2024 at 13:34, Alan DeKok <aland@deployingradius.com>
wrote:
On Sep 19, 2024, at 1:51 AM, nabble@felix.world wrote:
We had this issue years ago and after several meetings, mails,
capture
analysis the support just blamed FreeRADIUS…
If it helps, maybe email me off-list. I'm usually happy to join calls where I can pull rank on the vendor.
Vendor: FreeRADIUS Open Source, it's terrible. We're a billion dollar company, and filled with geniuses. Our product is perfect!
Alan: Hi! I've been doing RADIUS since 1997. When did you start your IT career? Oh, I've also written most of the RADIUS standards. And if I see that your product does things I don't like, I'll just update the next rev of the standards to forbid it. At which point your product will be official non-compliant with the RFCs. And your customers will be pointing this out during sales calls. Have a nice day!
Vendor: Uh... I guess we'll fix it then.
I've had these conversations many times.
Where facts, logic, and reason don't work, pulling rank generally works.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- [image: logo] <https://redirect.boostmymail.com/4Zm-4f0296580fcf4e5c80a33af00b0322c6> Luca Borruto IT System Administrator luca.borruto@agicap.com <https://redirect.boostmymail.com/4Zm-dc5779b061954defacc05e363a5696e4> <https://redirect.boostmymail.com/4Zm-7a8e60341d744b8bb02d1f09d7d5b840> [image: Linkedin] <https://redirect.boostmymail.com/4Zm-a07de2ddc5c94500afa93e8a4151b576> [image: Youtube] <https://redirect.boostmymail.com/4Zm-f49d8598b69d4a63a6cab44c1497ad69> [image: Campaign Banner] <https://redirect.boostmymail.com/4Zm-5e29a01133f74dd4bd8829ed49588743>
(4) eap_tls: ERROR: (TLS) TLS - Alert read:fatal:certificate unknown
‘read' means that your client is reporting that message. I assume that the CA certificate of your server is missing on the device or the server name in the WiFi profile is wrong/missing. BR, Lineconnect
You got this right! I don’t know why I forgot to add the server name in the profile… Thanks for this! On Fri 20 Sep 2024 at 10:01, <nabble@felix.world> wrote:
(4) eap_tls: ERROR: (TLS) TLS - Alert read:fatal:certificate unknown
‘read' means that your client is reporting that message. I assume that the CA certificate of your server is missing on the device or the server name in the WiFi profile is wrong/missing.
BR, Lineconnect
participants (4)
-
Alan DeKok -
George Benjin -
Luca Borruto -
nabble＠felix.world