RADSec: RADIUS over TLS
RADIUS was designed for a link between two boxes in the same building. It obscures one attribute — the password field — using a shared secret, and leaves everything else in the clear. That was a reasonable trade between a modem bank and a server down the hall. It is a poor one across the internet.
One thing first, because it is the honest qualifier: with EAP-TLS your certificates are not exposed by plain RADIUS either. The credential exchange happens inside the TLS handshake that EAP-TLS carries, so it is protected regardless of what the RADIUS packets ride in. What plain RADIUS leaves readable is everything around it.
RADSec is the fix, and it is not complicated: the same RADIUS conversation, carried inside a TLS connection, on port 2083. The equipment opens the connection outbound and keeps it open. Everything in it is encrypted, both ends can prove who they are with certificates rather than a password shared by everybody, and there is no inbound port to expose.
What it actually fixes
- The shared secret stops being the only thing between you and the network
- In plain RADIUS that secret protects one attribute and authenticates the client by possession. Everybody at the site holds it, it is typed into a controller once and rarely changed, and it is the same value on every switch and access point there. In RADSec the connection is authenticated by a certificate, which can be issued and revoked per site.
- The metadata stops being readable
- Who is connecting, from which device, through which access point or switch, onto which network, and the VLAN handed back. None of that is protected by plain RADIUS, and over the public internet it is visible to rather more people than the two you intended. It is not the certificate — that is safe either way — but it is a full picture of who works where and on what.
- There is no port to forward
- The connection is made outbound, from the equipment to us, and held open. Nothing at the site listens for anything, and there is no firewall rule to write, review or accidentally leave open.
- A dropped connection is visible
- TCP and TLS have a state that either exists or does not. Plain RADIUS is UDP: a request that vanishes and one that was refused look the same to the equipment, which is why the answer to “why could nobody connect on Monday” is so often unavailable.
The honest catch
Not everything speaks it. RADSec is well supported on access points and increasingly common elsewhere, but plenty of equipment — including UniFi switches — speaks standard RADIUS and has no second option. That is not a reason to avoid RADSec; it is a reason to know which of your equipment can use it before planning around it.
Passbeam answers on both transports, on the same endpoints, and a site can run one or the other or both at once. Standard RADIUS is not a lesser tier here — it is what a switch needs, and whether it is safe enough is a fair question with a real answer rather than a shrug.
One more, worth knowing before you plan a failover: equipment holds its RADSec connection open and will not re-resolve DNS. A second server in the profile is what redundancy looks like on real hardware, not a clever record with a short time-to-live.
How a shared endpoint knows who is calling
This is the question a hosted RADIUS service has to answer and rarely publishes. Passbeam runs one endpoint, not one per customer, so something has to decide — before a single RADIUS attribute is read — which organisation this connection belongs to. Get it wrong and one customer’s authentication log shows another’s.
The answer is the client certificate presented during the TLS handshake. Every site gets its own, issued by Passbeam and installed on that site’s equipment. It identifies the organisation and the individual office, which is what makes “which of this client’s three branches was that?” a question the log can answer at all.
Source IP address was considered for this and rejected. It fails on ordinary deployments — dynamic addresses change without warning, sites egress from whichever circuit is up, and two customers behind the same provider can present the same address. It remains available as an additional restriction for a client who wants one, and it is never the identifier. On the standard RADIUS side, where there is no client certificate to read, the registered addresses do that job and the shared secret authenticates the request.
What you configure
Two things per site, both generated for you: the client credential the equipment presents, and the trust bundle it needs so it will accept our listener’s certificate in return. On UniFi that is the TLS checkbox on the RADIUS profile — the controller does not use the word RADSec anywhere, which is worth knowing before you go looking for it. The rest of the UniFi setup is on its own page.
Which transport a given site should use is answered in the knowledge base, and the short version is: whichever your equipment speaks, and both if it is mixed.
Set up your first network in under 30 minutes
Create your Passbeam account, add a client — a customer, your company, or your own house — and follow the guided checklist through Entra, PKI, Intune and RADSec. Three steps rather than four if it is a network of printers and cameras.