Skip to Content

InkBridge Networks - A new name for Network RADIUS

What is a RADIUS proxy?

Don't stop at just one server

A RADIUS proxy is a RADIUS server configured to forward authentication requests to one or more other RADIUS servers rather than authenticating users directly. The proxy sits between the network access server (NAS) and the home RADIUS server that holds the user’s credentials. Proxies are the foundation of large-scale RADIUS architectures: they enable roaming federations like eduroam, let ISPs separate authentication for different customer segments, and allow enterprises to consolidate or split authentication traffic across multiple back-end servers. 


This article explains what a RADIUS proxy does, when proxying makes sense, and the architectural choices that determine whether a proxy deployment scales well or becomes a bottleneck. 


When to use a RADIUS proxy 

RADIUS proxying solves problems that a single RADIUS server cannot. The most common scenarios are: 

Roaming federations. eduroam, the global higher-education roaming network, runs entirely on RADIUS proxying. When a student from one university connects at another, the local RADIUS server proxies the authentication request back to the student’s home institution. Without proxies, federations of this scale would be impossible. 

ISP and telco scale. Large service providers route different classes of subscribers, regions, or service tiers to different RADIUS servers. Proxies do the routing, typically based on the realm portion of the username. 

Multi-site enterprises. A central proxy can route authentication to regional RADIUS servers, simplifying network management while keeping authentication latency low for end users. 

Outsourced authentication. Some organisations operate their own RADIUS proxy but outsource the actual credential checking to a managed authentication service. The proxy handles the network-side integration; the home server handles identity. 

Load distribution and failover. Proxies with home-server pools spread load across multiple back-end servers and fail over automatically when one becomes unresponsive. 

Our RADIUS proxy implementation in InkBridge RADIUS includes: 

  • Multiple realms, with
    • Realm determination on prefix
    • Realm determination on suffix
    • Realm determination on regular expressions
    • No limit on the number of home servers or realms
  • All internal data structures use hash maps or binary trees for scalability.
  • Home servers can be placed in different kinds of pools
  • Failover: Use the first one that is responsive
  • Load balancing: Divide the load evenly among the home servers
  • Keyed hash maps: Divide the load by hash, e.g., on username
  • Increased RADIUS server proxy stability over traditional methods, via:
    • Fine-grained control over when a home server is marked “dead”
    • Multiple methods for determining that a home server has become responsive
    • Requests can fail over from one home server to another
  • Policies can be set for:
    • When a packet is first proxied
    • When a response is received
    • When a packet fails to obtain a response
    • When all home servers are unresponsive
  • Custom proxying RADIUS server determination and algorithms

InkBridge RADIUS has been tested with 500,000 realms and home servers. Memory usage rises with the size of the realm table, but maximum proxying performance decreases by only a few percent at that scale. 

What does a RADIUS proxy server do? 

A RADIUS proxy server handles four core functions: 

Realm parsing. The proxy inspects each incoming request, identifies the realm (typically the portion of the username after the @ symbol), and looks up the corresponding home server or pool. 

Request forwarding. The proxy rewrites attributes where needed, then forwards the Access-Request to the chosen home server. It tracks the in-flight request so the response can be matched back to the originating NAS. 

Response handling. When the home server responds (Access-Accept, Access-Challenge, or Access-Reject), the proxy applies any local policies, optionally rewrites attributes again, and passes the response back to the NAS. 

Failover and health checking. If a home server becomes unresponsive, the proxy marks it dead, retries with another server in the pool, and continues health-checking the failed server in the background until it recovers. 

In comparison 

For most production proxy deployments, the question is not raw capacity - it is configurability: how flexibly you can route requests, control failover, and apply per-realm policies. That is where deployment-specific design matters most, and where in-house RADIUS expertise saves time and operational risk. 

Need more help?


InkBridge Networks has been at the forefront of network security for over two decades, tackling complex challenges across various protocols and infrastructures. Our team of seasoned experts has encountered and solved nearly every conceivable network security issue. If you're looking for insights from the architects behind some of the internet's most foundational authentication systems, you can request a quote for network security solutions here. 

Related Articles

Client Case Study: RADIUS Proxy

A case study on how InkBridge Networks were able to assist a client to increase the stability of their RADIUS proxy system. We were able to reuse common configuration, maintain existing capabilities and make proxying more robust. A faster failover and more reliable system helped lower ongoing costs and increase revenue.

Email addresses are primary user identifiers?

There is a lot of advice out there that email addresses are not identifiers. Even Internet2 has a document explaining why email is not an appropriate user identifier. What does this mean for RADIUS, especially since RFC 7542 allows using email addresses as identifiers? Speaking as the author of RFC 7542, I think I can help you.

in Blog