RadSec (RADIUS over TLS)

RadSec — RADIUS over TLS — wraps RADIUS traffic in a TLS session with mutual authentication. It’s the modern transport for federated roaming; eduroam’s international infrastructure has moved almost entirely off UDP RADIUS in favour of RadSec. If your Radius Proxy Context forwards to an eduroam federation, you’ll be using RadSec on the forwarding leg.

When to enable RadSec

• Always, for eduroam. The national federation tier-1 servers require RadSec. Plain UDP either isn’t accepted or is being phased out.
• For any Internet-traversing upstream. RADIUS’s UDP authenticator-hash security doesn’t survive a modern threat model on open networks. TLS solves the problem.
• When the upstream operator offers it. Even for non-eduroam roaming partnerships, RadSec on the forwarding leg is a reasonable default.

Keep UDP for the inside-the-Organization leg if your WLAN controllers don’t do RadSec — that’s a different conversation. This page is about the proxy → upstream leg.

Turning it on

1. Open the Context's Remote Radius Server tab

   This is where the upstream (proxy → upstream) RadSec toggle and its trusted certificate live. It’s a separate setting from the inbound RadSec terminator, which is configured on the Network Integration tab for the WLAN-controller side.

2. Enable RadSec

   Toggle Enable RadSec on.

3. Upload the RadSec CA

   The CA certificate the upstream server uses for its RadSec session. For eduroam, the federation operator publishes this as part of their RadSec onboarding instructions. Upload it through the Upload CA control on the RadSec card.

4. Point the Remote Radius Server at the RadSec port

   On Remote Radius Server, set the upstream port to the federation’s RadSec port (standard: 2083). Save.

5. Verify a test authentication

   Once the upstream operator has also allow-listed your deployment’s outbound FQDN, run a test authentication. The Context’s Devices / Online counters should pick up the test device within seconds.

What RadSec actually does on the wire

• TCP, not UDP. RADIUS packets travel inside a TLS session over TCP. Firewalls and NAT that previously needed to pass UDP 1812 / 1813 now see a TCP session on 2083.
• TLS, verified by certificate. RadSec verifies the upstream server using its CA — that’s the certificate you upload to EntryPoint. Where the upstream requires mutual authentication, a client certificate is presented on the forwarding leg as well.
• Transport encryption. The entire RADIUS payload — credentials, attributes, accounting — is confidential between EntryPoint and the upstream. Passive observers can’t see anything.

The protocol logic above the transport is still RADIUS. Attribute sets, username formats, accounting shape — identical to UDP RADIUS.

eduroam RadSec — the usual onboarding dance

The federation operator’s onboarding typically looks like:

1. You contact the federation operator and ask to join.
2. They send you their RadSec CA certificate and the hostname of their RadSec endpoint.
3. They ask you for your outbound FQDN (shown on the Remote Radius Server card).
4. They allow-list your FQDN on their side; you paste their hostname, port, and CA on your side.
5. Run a test RADIUS authentication end-to-end (visiting user from a roaming institution joining an eduroam SSID on your campus). If it succeeds, you’re joined.

Budget a few days between each of the coordination steps — it’s typically email-paced on the federation side. The technical work on EntryPoint’s side is a few minutes.

Operational notes

• The RadSec CA needs to be current. Federations rotate their CA on a multi-year cadence. When notified of a rotation, upload the new CA alongside the old one, verify authentications still work, then remove the old CA.
• RadSec port is TCP, not UDP. Firewalls allowing only UDP RADIUS will block RadSec. Re-check the path to the upstream after enabling.
• Accounting piggybacks on the same session. No separate accounting-port concern when RadSec is on.
• Inbound RadSec on the Context itself. EntryPoint also supports RadSec for the WLAN-controller side of the Context. See RADIUS clients. The two uses (inbound from your WLAN; outbound to the upstream) are independent toggles in the admin UI — you can run one or both.

Troubleshooting

• TLS handshake errors. The RadSec CA on your side doesn’t match the upstream’s RadSec certificate. Re-download the CA from the federation operator and re-upload.
• “Connection refused” / “Timeout”. The upstream hasn’t allow-listed your outbound FQDN yet, or a firewall between you and the upstream is dropping TCP 2083. Check with the federation operator.
• Authentications succeed but accounting rows don’t arrive. Rare — RadSec carries accounting on the same session. More likely a RADIUS-accounting issue on the WLAN controller side; see EntryPoint diagnostics.

Related

Remote Radius Server

Hostname, ports, secret — where RadSec is pointed.

Radius Proxy overview

The variant at a glance.

RADIUS clients

RadSec on the inbound side, from your WLAN to the Context.

Trusted certificates

CA management for EAP-TLS; separate from RadSec CAs but same mental model.