Skip to main content
The Radius Proxy variant — EntryPoint 2.0 (Radius Proxy / eduroam) — forwards RADIUS authentication and accounting to an upstream RADIUS server of your choosing. EntryPoint doesn’t store credentials, validate certificates, or look up device MACs in its own database; every request is handed off to a remote server that answers on behalf of its own identities. The hero use case is eduroam — the international federation that lets visiting researchers authenticate against their home institution’s identity service while roaming on a host institution’s Wi-Fi. Universities deploying eduroam point their campus Wi-Fi at an EntryPoint Radius Proxy Context, which forwards upward to their national eduroam federation tier.

​
How forwarding works

1

A visiting user's device associates to an eduroam SSID

The user is a student from another institution, visiting your campus. Their device is already configured for eduroam.
2

The WLAN controller sends a RADIUS Access-Request

Username format user@their-home-domain.edu. Destined for the Radius Proxy Context on your EntryPoint deployment.
3

EntryPoint forwards upstream

The Context’s Remote Radius Server configuration tells it where to send the request — typically the national eduroam federation server. Forwarding uses RADIUS over UDP or RadSec, depending on what the federation supports.
4

The federation routes onward

Through the eduroam hierarchy, the request reaches the user’s home institution’s RADIUS server.
5

Access-Accept propagates back

The home institution returns Access-Accept (or Reject) to the federation, which returns it to your EntryPoint Context, which returns it to your WLAN controller. The visitor joins the SSID.
Your EntryPoint Context is a transparent forwarder. The actual authorization decision is made by whichever institution owns the visitor’s identity.

​
Single Default Device Group — no Self-Service, no variants

A Radius Proxy Context looks different from the other three variants on the Configuration page. It exists to forward traffic, not to host per-audience policy:
  • Exactly one Group. The Default Device Group is auto- created with the Context; the Add Group action is disabled. There’s no mental model of “one Group per audience” here — every forwarded authentication attaches to this single Group.
  • No Self-Service portal. A proxy has no local identities, so there’s nothing for an end-user to see. Self-Service routes are hidden across the UI for Radius Proxy Contexts.
  • No per-user or per-device admin. Membership is not a concept here. The federation decides who gets in.
What the Default Device Group does carry is one Attribute Profile — the RADIUS-response bundle EntryPoint adds to every proxied authentication. This is how you put visiting users onto a specific VLAN (a guest VLAN, a firewalled research network, etc.) regardless of what the upstream home institution sent back. See Default Device Group.

​
Configuration surface

A Radius Proxy Context’s Configuration tabs are:
TabPurpose
Basic ConfigurationContext name, description, a link to the Default Device Group.
Remote Radius ServerThe upstream hostname, ports, shared secret, RadSec toggle + CA. See Remote Radius Server.
Attribute ProfilesShared with other variants; attach to the Default Device Group to drive VLAN / SGT / tunnel on the client side.
Network IntegrationShared — hostname, ports, per-Context shared secret, IP allow-list, RadSec. See RADIUS clients.

​
What Radius Proxy is NOT

  • Not a local identity store. No PEAP accounts, no certificate lookups, no MAC lists. Every authentication is forwarded.
  • Not a group-per-audience story. One Default Device Group exists. Per-audience segmentation happens in your WLAN / VLAN design, not in EntryPoint Groups.
  • Not a Self-Service surface. No portal. Don’t try to invite users or manage fleets here — the other three variants are where those stories live.
  • Not a captive portal or OTP service. For short-stay visitors without a roaming federation, look at Sign In instead.

​
Other use cases beyond eduroam

Most Radius Proxy deployments are eduroam, but the same mechanism works anywhere you want to forward authentication to a remote RADIUS endpoint:
  • Roaming partnerships between two Organizations. Two institutions or Organizations agree to mutually honour each other’s identities on a shared SSID. Each deploys a Radius Proxy Context pointed at the other’s RADIUS.
  • Migration bridging. During a transition from an existing on-prem RADIUS to EntryPoint, a Radius Proxy can forward to the legacy server while identity-migration work proceeds elsewhere. Short-term rather than permanent.
  • Outbound connectivity to a vendor-hosted RADIUS. Specific appliance vendors sometimes want EAP-based auth against their own RADIUS; a proxy Context gives you a single place to manage that forwarding from inside the Organization.
In every case, the one-Group, one-Attribute-Profile shape applies.

​
Who operates Radius Proxy

Organization administrators only. Lifecycle is thin:
  1. Create the Context — Creating a Context.
  2. Configure the Remote Radius Server — Remote Radius Server.
  3. Enable RadSec if the upstream (eduroam, always) requires it.
  4. Attach an Attribute Profile to the Default Device Group for VLAN policy — Default Device Group.
  5. Attach your WLAN controllers / APs to the Context’s RADIUS endpoint — RADIUS clients.
From that point, the Context runs itself. Audit and forward.

​
Prerequisites

  • An EntryPoint Context of type EntryPoint 2.0 (Radius Proxy / eduroam) — Creating a Context.
  • The upstream RADIUS server’s hostname, ports, and shared secret. For eduroam, this comes from your national federation operator.
  • For RadSec: the CA certificate the upstream uses for its RadSec session.
  • Agreement from the upstream operator to allow connections from your EntryPoint deployment’s egress FQDN — the Remote Radius Server configuration displays the FQDN you need to share with them.

​
Where to go next

Remote Radius Server

Configure the upstream hostname, ports, and shared secret.

RadSec (RADIUS over TLS)

The standard for federated roaming today; required by eduroam.

Default Device Group

Where the single Group lives and how the Attribute Profile attaches.

RADIUS clients

Attach your WLAN controllers to the Context on the client side.