Unifi: Unable to connect to STUN server

Some time ago, I got a notice that several of my Unifi devices were “unable to connect to STUN server”. They still functioned, and I’m moving away from Unifi for lots of things, so I didn’t really give a shit.

But today, in the process of doing something else, it started to annoy me so I wanted to look into it. The culprit? My Unifi controller is hosted on my home Kubernetes cluster, and it uses MetalLB for the “inform” host, and the STUN port is not exposed on the load balancer I chose.

Why? I seem to recall that when I set up MetalLB that I read you were unable to have multiple ports on the same LB IP, which led me to make some questionable design decisions (like Traefik not exposing an HTTP port, only HTTPS). So only the inform port is configured on the LB assigned to Unifi (the Unifi web UI goes via Traefik).

So I started to think (and thus, grumble) about having to replace MetalLB with something else, and I just decided to google the problem and well whaddya know, MetalLB does support sharing IPs between multiple services! More interestingly, it appears it has done so since 2018, well before I started using it, so I guess I must have simply read outdated information (isn’t that awesome) when I made those decisions.

Once I configured a sensible metallb.universe.tf/allow-shared-ip key and duplicated the service, set the ports correctly, re-applied… it still didn’t work. nmap the LB IP and… the port is closed? After looking again at the documentation, STUN is UDP, so that’s easy enough to fix.

Did that and before I could even think about logging into one of the switches that was complaining, the little alert disappeared on each of them one by one. Nice!

Update: 2023-01-11: That wasn’t the reason the devices kept disconnecting from the controller, as they’re still doing it. :(

Horsham, VIC, Australia fwaggle



Filed under:


Horsham, VIC, Australia

Navigation: Older Entry Newer Entry