Configuring FreeRADIUS Behind Azure Load Balancer - Health Probe Issue
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
Hi Luca, What is your ingress controller to handle the TCP route? We’ve the same setup but with Traefik in front of FreeRADIUS which also solves your problem since Traefik will have the port open even if there is no radius server behind it. And in regards to the startup-probe for the container, you can add the node IP (where the probes will be send from) as environment variable to allow connections from it. Besides that I would use the K8S functionalities to ensure that the service is healthy like PDB, horizontal pod autoscaling etc. BR, Lineconnect
On 7. Feb 2025, at 09:20, Luca Borruto via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi and thanks for your response, Currently I’m trying to configure FreeRADIUS without an ingress controller, just behind the Azure Load Balancer, however, since you got it working with Traefik I will try it (I'm using haproxy but don't mind switching to Traefik, it's a new cluster). I'm fairly new to k8s so I'm still on the learning side... Could you share more details on how you configured Traefik behind the Azure Load Balancer? Did you just add the ingress? Are clients preserving their IP? Do you need additional configuration on freeradius side? I came across this but not sure if that's related to what I want to achieve : https://www.freeradius.org/documentation/freeradius-server/3.2.7/howto/proto... Appreciate any insights you can provide, Le ven. 7 févr. 2025 à 10:54, <nabble@felix.world> a écrit :
Hi Luca,
What is your ingress controller to handle the TCP route? We’ve the same setup but with Traefik in front of FreeRADIUS which also solves your problem since Traefik will have the port open even if there is no radius server behind it. And in regards to the startup-probe for the container, you can add the node IP (where the probes will be send from) as environment variable to allow connections from it. Besides that I would use the K8S functionalities to ensure that the service is healthy like PDB, horizontal pod autoscaling etc.
BR, Lineconnect
On 7. Feb 2025, at 09:20, Luca Borruto via Freeradius-Users < freeradius-users@lists.freeradius.org> wrote:
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 - 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-bab88183ed3e45d38932a06020f826db>
It should also work with HAProxy(or any other ingress controller which is able to handle TCP routes and PROXY protocol). I’ve just used it before and never had any issues with it, therefore also never searched for a alternative.
Could you share more details on how you configured Traefik behind the Azure Load Balancer?
Add their CRDs to your cluster and add a IngressRouteTCP object.
Did you just add the ingress? A normal ingress is HTTP only.
Are clients preserving their IP? Yes. How this can be accomplished is different depending on the managed K8S provider. Have a look on the externalTrafficPolicy and yes you’ll also need PROXY Protocol to preserve the client IP from your ingress controller to the actual service/pod.
But just google on how you can preserve the actual client IP address in AKS. BR, Lineconnect
On 7. Feb 2025, at 11:42, Luca Borruto <luca.borruto@agicap.com> wrote:
Hi and thanks for your response, Currently I’m trying to configure FreeRADIUS without an ingress controller, just behind the Azure Load Balancer, however, since you got it working with Traefik I will try it (I'm using haproxy but don't mind switching to Traefik, it's a new cluster). I'm fairly new to k8s so I'm still on the learning side... Could you share more details on how you configured Traefik behind the Azure Load Balancer? Did you just add the ingress? Are clients preserving their IP? Do you need additional configuration on freeradius side? I came across this but not sure if that's related to what I want to achieve : https://www.freeradius.org/documentation/freeradius-server/3.2.7/howto/proto... Appreciate any insights you can provide,
Le ven. 7 févr. 2025 à 10:54, <nabble@felix.world> a écrit : Hi Luca,
What is your ingress controller to handle the TCP route? We’ve the same setup but with Traefik in front of FreeRADIUS which also solves your problem since Traefik will have the port open even if there is no radius server behind it. And in regards to the startup-probe for the container, you can add the node IP (where the probes will be send from) as environment variable to allow connections from it. Besides that I would use the K8S functionalities to ensure that the service is healthy like PDB, horizontal pod autoscaling etc.
BR, Lineconnect
On 7. Feb 2025, at 09:20, Luca Borruto via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Luca Borruto IT System Administrator luca.borruto@agicap.com
Hi, I successfully configured FreeRADIUS behind Traefik, and it’s working pretty well! The only downside is that I can’t figure out how to configure IP preservation—clients arrive at the server with the internal Traefik pod IP (10.0.2.7). I have a network security group that allows only our offices public IPs, so it’s not really an issue, but I would still like to debug this. For the record, here’s my current Helm configuration for Traefik: ``` traefik: deployment: replicas: 2 ports: radsec: port: 2083 expose: default: true protocol: TCP tls: passthrough: true nodeSelector: nodepool-tag: "system" additionalArguments: - "--entryPoints.radsec.address=:2083" - "--providers.file.watch=true" - "--entryPoints.radsec.proxyProtocol.insecure=true" service: type: LoadBalancer spec: loadBalancerIP: "redacted" externalTrafficPolicy: Local annotations: service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path: "/healthz" providers: file: enabled: true watch: true content: | tcp: routers: radsec-router: entryPoints: - radsec rule: "HostSNI(`*`)" service: radsec-service tls: passthrough: true services: radsec-service: loadBalancer: servers: - address: "raddb-freeradius-server.radius.svc.cluster.local:2083" proxyProtocol: version: 1 ``` Le ven. 7 févr. 2025 à 12:01, <nabble@felix.world> a écrit :
It should also work with HAProxy(or any other ingress controller which is able to handle TCP routes and PROXY protocol). I’ve just used it before and never had any issues with it, therefore also never searched for a alternative.
Could you share more details on how you configured Traefik behind the Azure Load Balancer?
Add their CRDs to your cluster and add a IngressRouteTCP object.
Did you just add the ingress? A normal ingress is HTTP only.
Are clients preserving their IP? Yes. How this can be accomplished is different depending on the managed K8S provider. Have a look on the externalTrafficPolicy and yes you’ll also need PROXY Protocol to preserve the client IP from your ingress controller to the actual service/pod.
But just google on how you can preserve the actual client IP address in AKS.
BR, Lineconnect
On 7. Feb 2025, at 11:42, Luca Borruto <luca.borruto@agicap.com> wrote:
Hi and thanks for your response, Currently I’m trying to configure FreeRADIUS without an ingress controller, just behind the Azure Load Balancer, however, since you got it working with Traefik I will try it (I'm using haproxy but don't mind switching to Traefik, it's a new cluster). I'm fairly new to k8s so I'm still on the learning side... Could you share more details on how you configured Traefik behind the Azure Load Balancer? Did you just add the ingress? Are clients preserving their IP? Do you need additional configuration on freeradius side? I came across this but not sure if that's related to what I want to achieve : https://www.freeradius.org/documentation/freeradius-server/3.2.7/howto/proto... Appreciate any insights you can provide,
Le ven. 7 févr. 2025 à 10:54, <nabble@felix.world> a écrit : Hi Luca,
What is your ingress controller to handle the TCP route? We’ve the same setup but with Traefik in front of FreeRADIUS which also solves your problem since Traefik will have the port open even if there is no radius server behind it. And in regards to the startup-probe for the container, you can add the node IP (where the probes will be send from) as environment variable to allow connections from it. Besides that I would use the K8S functionalities to ensure that the service is healthy like PDB, horizontal pod autoscaling etc.
BR, Lineconnect
On 7. Feb 2025, at 09:20, Luca Borruto via Freeradius-Users < freeradius-users@lists.freeradius.org> wrote:
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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Luca Borruto IT System Administrator luca.borruto@agicap.com
-- [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-bab88183ed3e45d38932a06020f826db>
On Feb 10, 2025, at 11:08 AM, Luca Borruto via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
I successfully configured FreeRADIUS behind Traefik, and it’s working pretty well!
That's good.
The only downside is that I can’t figure out how to configure IP preservation—clients arrive at the server with the internal Traefik pod IP (10.0.2.7).
Configure the haproxy protocol on Traefik and on FreeRADIUS. FreeRADIUS will automatically pick up the original source IP. See sites-available/tls. Look for "haproxy".
I have a network security group that allows only our offices public IPs, so it’s not really an issue, but I would still like to debug this. For the record, here’s my current Helm configuration for Traefik:
Why? This is the FreeRADIUS list. We can't give advise on other peoples software. Alan DeKok.
Hi, I would strongly recommend to not use the file provider and use the functionalities of traefik and k8s. Most of the configuration you’ve made can be done with CRDs and ingress classes. And for the rest. I think you’re able to figure that out on your own. It works and FreeRADIUS is able to deal with the PROXY protocol, which is the only point which is relevant for this mailing list. BR, Lineconnect
On 10. Feb 2025, at 17:08, Luca Borruto <luca.borruto@agicap.com> wrote:
Hi, I successfully configured FreeRADIUS behind Traefik, and it’s working pretty well! The only downside is that I can’t figure out how to configure IP preservation—clients arrive at the server with the internal Traefik pod IP (10.0.2.7). I have a network security group that allows only our offices public IPs, so it’s not really an issue, but I would still like to debug this. For the record, here’s my current Helm configuration for Traefik: ``` traefik: deployment: replicas: 2 ports: radsec: port: 2083 expose: default: true protocol: TCP tls: passthrough: true
nodeSelector: nodepool-tag: "system"
additionalArguments: - "--entryPoints.radsec.address=:2083" - "--providers.file.watch=true" - "--entryPoints.radsec.proxyProtocol.insecure=true"
service: type: LoadBalancer spec: loadBalancerIP: "redacted" externalTrafficPolicy: Local annotations: service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path: "/healthz"
providers: file: enabled: true watch: true content: | tcp: routers: radsec-router: entryPoints: - radsec rule: "HostSNI(`*`)" service: radsec-service tls: passthrough: true services: radsec-service: loadBalancer: servers: - address: "raddb-freeradius-server.radius.svc.cluster.local:2083" proxyProtocol: version: 1 ```
Le ven. 7 févr. 2025 à 12:01, <nabble@felix.world> a écrit : It should also work with HAProxy(or any other ingress controller which is able to handle TCP routes and PROXY protocol). I’ve just used it before and never had any issues with it, therefore also never searched for a alternative.
Could you share more details on how you configured Traefik behind the Azure Load Balancer?
Add their CRDs to your cluster and add a IngressRouteTCP object.
Did you just add the ingress? A normal ingress is HTTP only.
Are clients preserving their IP? Yes. How this can be accomplished is different depending on the managed K8S provider. Have a look on the externalTrafficPolicy and yes you’ll also need PROXY Protocol to preserve the client IP from your ingress controller to the actual service/pod.
But just google on how you can preserve the actual client IP address in AKS.
BR, Lineconnect
On 7. Feb 2025, at 11:42, Luca Borruto <luca.borruto@agicap.com> wrote:
Hi and thanks for your response, Currently I’m trying to configure FreeRADIUS without an ingress controller, just behind the Azure Load Balancer, however, since you got it working with Traefik I will try it (I'm using haproxy but don't mind switching to Traefik, it's a new cluster). I'm fairly new to k8s so I'm still on the learning side... Could you share more details on how you configured Traefik behind the Azure Load Balancer? Did you just add the ingress? Are clients preserving their IP? Do you need additional configuration on freeradius side? I came across this but not sure if that's related to what I want to achieve : https://www.freeradius.org/documentation/freeradius-server/3.2.7/howto/proto... Appreciate any insights you can provide,
Le ven. 7 févr. 2025 à 10:54, <nabble@felix.world> a écrit : Hi Luca,
What is your ingress controller to handle the TCP route? We’ve the same setup but with Traefik in front of FreeRADIUS which also solves your problem since Traefik will have the port open even if there is no radius server behind it. And in regards to the startup-probe for the container, you can add the node IP (where the probes will be send from) as environment variable to allow connections from it. Besides that I would use the K8S functionalities to ensure that the service is healthy like PDB, horizontal pod autoscaling etc.
BR, Lineconnect
On 7. Feb 2025, at 09:20, Luca Borruto via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Luca Borruto IT System Administrator luca.borruto@agicap.com
-- Luca Borruto IT System Administrator luca.borruto@agicap.com
participants (3)
-
Alan DeKok -
Luca Borruto -
nabble＠felix.world