Configuring FreeRADIUS Behind Azure Load Balancer - Health Probe Issue

[Luca Borruto]

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/protocols/proxy/index.html

Appreciate any insights you can provide,

Le ven. 7 févr. 2025 à 10:54, <nabble at 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 at 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 at 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>