Configuring FreeRADIUS Behind Azure Load Balancer - Health Probe Issue

[Luca Borruto]

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 at 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 at 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/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
> >
> >
> >
> > --
> > Luca Borruto
> > IT System Administrator
> >  luca.borruto at agicap.com
>
>

-- 
[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>