TLDR
- A proxy chooses the next hop from the realm in User-Name, and the home server makes the authentication decision (RFC 2865, Section 2.3).
- A proxy may add one Proxy-State on the way out and must remove it on the way back (RFC 2865, Section 5.33).
- RADIUS has no built-in loop detection, so realm tables must be designed to avoid loops (RFC 7585, Section 3.4.4).
- RadSec (RFC 6614, Section 2.1) protects each hop, but every proxy still reads the attributes it forwards.
- A RADIUS proxy receives an authentication or accounting request, reads the realm in the user name (for example user@example.net), and forwards the request to the home server for that realm. It adds a Proxy-State attribute so the reply can be routed back, and relays the answer to the original network access server (NAS).
- RADIUS (Remote Authentication Dial-In User Service) is defined in RFC 2865. This guide covers realm routing, Proxy-State and Class, and three operator setups: a mobile virtual network operator (MVNO), wholesale broadband and roaming Wi-Fi. For protocol basics, start with RADIUS Protocol Explained.
What a RADIUS proxy does
RFC 2865, Section 2.3, defines proxy operation. A NAS such as a broadband network gateway (BNG) or wireless LAN controller (WLC) sends its Access-Request to a forwarding server. The forwarding server relays it to a remote server, called the home server in this guide, and returns the reply. Proxies can be chained, and one server can forward some realms while acting as home server for others.
Realm routing
The realm is the part of the user name after the @. The NAS places the full Network Access Identifier (NAI), such as user@mvno.example.net, in the User-Name attribute (RFC 2865, Section 5.1; RFC 7542, Section 2.2).
The proxy treats the NAI realm as a key in a routing table, and each entry points to one or more next-hop servers. Intermediate nodes must use the realm without modification (RFC 7542, Section 3). Routing can also use another criterion, such as Called-Station-Id, which RFC 2865 calls a numbered realm (Section 2.3).
The home server should reject any NAI whose realm it does not host (RFC 7542, Section 3, as corrected by erratum 5462). RFC 7585, Section 3.4, defines Experimental dynamic discovery: the proxy looks up the realm in DNS to find the home server.
Proxy-State and Class
A forwarding server may add one Proxy-State when it forwards a request, placed after any already present (RFC 2865, Section 2.3). The home server must copy every Proxy-State into its reply, unmodified and in order (Section 5.33).
On the way back, the proxy removes its Proxy-State and re-signs the reply, since the change invalidates the Response Authenticator (RFC 2865, Section 3). RFC 2865 leaves the content to the implementation, so a proxy can use it to carry context it needs when the reply returns.
Class works the other way. The home server may send Class in an Access-Accept, and the NAS returns it unmodified in accounting (Section 5.25). A forwarding server must not modify Class, State or other servers’ Proxy-State attributes (Section 2.3).
| Attribute | Set by | Purpose | Source |
| User-Name | NAS | Carries the NAI; the realm selects the next hop | RFC 2865, Section 5.1; RFC 7542, Section 3 |
| Proxy-State | Forwarding server | Opaque marker added going out and removed coming back | RFC 2865, Section 5.33 |
| Class | Home server | Opaque value the NAS returns in accounting | RFC 2865, Section 5.25 |
| Operator-Name | NAS | Identifies the operator that owns the NAS | RFC 5580, Section 4.1 |
Proxy, gateway or broker
RFC 2865 defines only the proxy role. Gateway and broker are industry terms, so the definitions below are working ones.
| Term | Working definition | Typical use | Basis |
| Proxy | Forwards requests by realm and relays the reply | MVNO, wholesale and roaming routing | RFC 2865, Section 2.3 |
| Gateway | Converts between protocols or transports, such as RADIUS to Diameter, or RADIUS/UDP to RADIUS/TLS | Joining access networks to a different core or transport | Industry usage |
| Broker | A proxy run as a shared hub, so each partner keeps one connection instead of one per partner | Roaming hubs and clearinghouses | Industry usage; RFC 7585, Section 6 says “clearinghouse” |
Because the roles combine (RFC 2865, Section 2.3), check that your AAA Server can do both.
Three operator topologies
Each setup uses the same mechanics for a different commercial reason. Realms in the examples are example.net placeholders, and each diagram shows three nodes.
1. MVNO
An MVNO owns its subscribers and its realm, but its subscribers use access on a host network. The host network runs the proxy, and the MVNO runs the home server for mvno.example.net.
Worked example: the host network’s NAS sends an Access-Request for user@mvno.example.net. The proxy finds the realm in its table, adds a Proxy-State and forwards the request. The home server checks the subscriber record, which an MVNO typically holds in subscriber data management, and returns an Access-Accept with a Class value.
The proxy then removes its own Proxy-State, re-signs the reply and returns it to the NAS. Agree the realm with the host network before the first subscriber is provisioned, and reject unknown realms instead of forwarding them (RFC 7542, Section 3). For the commercial side, see launching an MVNO.
2. Wholesale broadband
A wholesale operator owns the access network, such as its BNGs, and several retail internet service providers (ISPs) sell service over it. Each retail ISP has its own realm, such as isp.example.net, and its own home server.
The wholesale proxy routes each subscriber’s requests to the right retail ISP by realm. It also decides which attributes to accept back. RFC 2865, Section 2.3, warns about passing Service-Type values such as Administrative or NAS-Prompt through in a proxied Access-Accept.
3. Roaming Wi-Fi
A venue’s WLC sends requests to a roaming hub, which forwards them to each user’s home network. The hub works like the broker defined above, so a venue needs one connection instead of one per home network.
With tunneled Extensible Authentication Protocol (EAP) methods, the outer identity can be anonymous@home.example.net. The proxy routes on the realm, and the real user name stays inside the tunnel, hidden from the visited network (RFC 7542, Section 2.4).
The WLC also sends Operator-Name so the home network knows which operator owns the access network (RFC 5580, Section 4.1). Dynamic discovery can remove proxies used only for routing, which reduces the number of entities that can inspect traffic (RFC 7585, Section 6).
Accounting through a proxy
Accounting follows the same realm route as authentication (RFC 2866, Section 2.1). The forwarding server can log the Accounting-Request, add its Proxy-State, update the Request Authenticator and forward it. The remote server copies Proxy-State into the Accounting-Response, and the proxy removes its own before replying to the NAS.
Class returns to the home operator in accounting, so usage can be tied to its own Access-Accept (RFC 2865, Section 5.25). The start and stop records of one session share an Acct-Session-Id (RFC 2866, Section 5.5).
The proxy’s own log gives a wholesale operator a record to reconcile against partner statements. With dynamic discovery, accounting servers are discovered separately from authentication servers (RFC 7585, Section 3.1).
Securing proxy links
Classic RADIUS obfuscates passwords with a shared secret and MD5. A proxy holding that secret can read them (RFC 2865, Section 2.3; RFC 7585, Section 6). RadSec carries RADIUS over Transport Layer Security (TLS) on TCP port 2083 (RFC 6614, Section 2.1, an Experimental RFC).
Each hop is protected, but each proxy ends its own connections and still reads what it forwards. Choose authentication methods that never use User-Password, such as certain EAP types (RFC 7585, Section 6).
A working IETF draft, draft-ietf-radext-deprecating-radius (version 10, July 2026), proposes deprecating insecure uses of RADIUS, including RADIUS/UDP and RADIUS/TCP, but it is not yet an RFC.
Loop prevention and failover
RADIUS has no built-in loop detection (RFC 7585, Section 3.4.4), and RFC 2865, Section 2.3, warns that proxy chains can loop. Give each realm one home server, reject realms you do not host, and never point two proxies at each other for unknown realms. RFC 7542, Section 3.3.1, says decorated NAIs that spell out a route are not recommended in RADIUS.
For failover, list more than one next hop per realm. RFC 2865, Section 2, lets a client try an alternate server but does not specify retries, and Section 2.6 discourages test requests. Alepo’s AAA Server datasheet lists 99.999% availability, a fair bar for a proxy tier that sits in front of every partner login.
FAQs
Q1. What is a RADIUS proxy?
A server that forwards RADIUS authentication and accounting requests to the home server for the user’s realm, then relays the reply (RFC 2865, Section 2.3).
Q2. How does realm routing work?
The proxy reads the realm in User-Name, looks it up in a routing table and forwards to that realm’s next hop (RFC 7542, Section 3).
Q3. What is Proxy-State?
Proxy-State is attribute 33. A forwarding server may add one when forwarding. The home server copies it back unmodified, and the proxy removes its own before replying (RFC 2865, Section 5.33).
Q4. What is the difference between a RADIUS proxy and a RADIUS server?
A server answers from its own user records. A proxy forwards the request to another server. One server can do both, for different realms (RFC 2865, Section 2.3).
Q5. What is the difference between a gateway, a proxy and a broker?
A proxy forwards by realm. A gateway converts between protocols or transports. A broker is a proxy run as a shared hub for many partners. Only the proxy role is defined in RFC 2865.
Q6. Does a RADIUS proxy see passwords?
With User-Password, yes. The proxy recovers the password using the secret it shares with the NAS, then hides it again for the next hop (RFC 2865, Section 2.3). EAP methods that never use User-Password avoid this (RFC 7585, Section 6).
Q7. How are proxy loops avoided?
RADIUS has no built-in loop detection (RFC 7585, Section 3.4.4). Give each realm one home server, reject realms you do not host, and avoid decorated NAIs (RFC 7542, Section 3.3.1).
Q8. How does accounting reach the right partner?
The proxy applies the same realm table to each Accounting-Request, forwards it, and returns the partner’s Accounting-Response (RFC 2866, Section 2.1).
Conclusion
A RADIUS proxy comes down to one decision per realm: which server answers for it. Get the realm table right, leave Proxy-State and Class intact, and send accounting down the same route as authentication. Then protect each hop, add a second next hop for failover, and check that no realm routes back to where it came from.
Planning realms for an MVNO or a multi-tenant network? Book a demo and work through your setup with our team.
