In RADIUS proxying, how does a forwarding server decide which server an Access-Request goes to next?
answer
- routing needs a key in the packet
- look inside User-Name (1)
- the portion after the @
- no suffix - route on the endpoint
- forwarding position versus remote position
basics
~20 sIt routes on something the request already carries. Usually that is a named realm - the realm portion of a Network Access Identifier in User-Name (1) - matched against a local routing table. Otherwise it routes on another attribute, classically Called-Station-Id (30).
solid answer
~40 sA forwarding server makes a **local** routing decision from the contents of the request. The common case is a **named realm**: `User-Name (1)` carries a Network Access Identifier of the form `user@realm`, and the realm portion is matched against a routing table that names the next hop. The alternative is a **numbered realm**: the identity string carries no routing information, so the decision is taken on another attribute - classically `Called-Station-Id (30)`, which says which network endpoint was contacted. RFC 2865 section 2.6 separates the **forwarding server**, which relays a request onward and relays the reply back, from the **remote server**, which actually decides. One machine can be both, realm by realm: it decides for its own realm and forwards everything else.
code
pseudocode · 15 linesfunction choose_next_hop(access_request):
name = value of User-Name (1) in access_request
if name contains @:
realm = portion of name after the last @
if realm is served locally:
return decide_here(access_request) # remote server
if realm in named_realm_table:
return forward_to(named_realm_table[realm]) # forwarding server
called = value of Called-Station-Id (30) in access_request
if called in numbered_realm_table:
return forward_to(numbered_realm_table[called])
return unroutable(access_request) # local policy: drop, or Access-Reject (Code 3)go deeper
Know that proxying exists and that the destination is derived from the request rather than known in advance. The suffix after the @ in the login name is the usual key.
Name both keys - the realm portion of a Network Access Identifier, and an attribute such as Called-Station-Id (30) - and explain that forwarding and deciding are positions in one exchange, not two kinds of machine.
Talk about the failure modes: an unrouted realm, a catch-all that swallows typos, a renamed endpoint that silently re-points logins. Say which of the two keys you would provision for a short-lived multi-organisation site.
The judgment is who carries the burden. A named realm pushes it onto every visiting user's login string; a numbered realm pushes it onto your own endpoint provisioning. Pick the one your operations can actually keep correct.
## Routing needs something to route on A forwarding server has an `Access-Request (Code 1)` in hand and must choose a next hop before it can do anything useful. Nothing in the exchange tells it where the request should go, so it derives that from the request's own contents and its local configuration. Two derivations are in common use. ## Named realms The identity string carries its own destination. `User-Name (1)` holds a **Network Access Identifier** shaped `user@realm`, and the realm portion is the routing key: - the forwarding server takes the realm from the name; - if the realm is one it serves, it decides locally and is a remote server for this request; - otherwise it looks the realm up in a routing table and relays the request to the next hop named there. The cost is on the user's side: everyone from a visiting organisation has to type a decorated name, and a name typed without its realm is unroutable. ## Numbered realms Sometimes the identity cannot be decorated - the credential predates the arrangement, or the organisation will not change how its staff log in. The routing key then moves off the identity and onto the circumstances of the attempt. The classic key is `Called-Station-Id (30)`, the endpoint that was contacted, so that connecting to one advertised endpoint routes you to one home server and connecting to another routes you elsewhere. | | named realm | numbered realm | |---|---|---| | routing key | realm portion of `User-Name (1)` | another attribute, classically `Called-Station-Id (30)` | | user must | log in with a decorated name | nothing - the network endpoint decides | | breaks when | the suffix is mistyped or omitted | an endpoint is renamed or re-provisioned | | provisioning | one entry per realm | one entry per endpoint | ## Forwarding server or remote server RFC 2865 section 2.6 names the two positions a server can occupy: - a **forwarding server** relays a request toward another server and relays the reply back down; - a **remote server** is the one that actually decides. They are positions in one exchange, not permanent properties of a machine. One host is routinely both: it answers for the realms it serves and forwards the rest. At an agricultural showground, the on-site server is a remote server for the site's own staff accounts and a forwarding server for a dozen visiting exhibitor realms, in the same second, from the same table. ## Failure modes worth recognising 1. **A realm with no route.** Local policy decides what happens - typically the request is dropped or answered with an `Access-Reject (Code 3)`. To the user, a mistyped realm and a broken home server look the same. 2. **A default route that catches typos.** A catch-all entry makes unroutable names routable to the wrong operator, which fails slowly and confusingly rather than quickly. 3. **Bare names on a named-realm deployment.** Nothing can be derived, so the request cannot be forwarded at all unless a second key is configured. 4. **An endpoint renamed under a numbered-realm deployment.** The routing key changes silently and logins start arriving at the wrong home server with no configuration having been edited. ## Why an interviewer asks this Because it separates candidates who think a proxy 'knows where the user belongs' from candidates who can say what field the knowledge is read out of, and who can name what happens when that field is missing. The realm is also one of the most overloaded words in this material: a RADIUS realm suffix is not a ticket-based authentication realm, and neither is the realm string in a web authentication challenge. Say which you mean.
- What does routing on Called-Station-Id (30) instead of a realm suffix cost you?It moves the routing key off the identity and onto the network endpoint, so users need no decorated name - but every endpoint has to be provisioned and kept correct. A renamed or re-provisioned endpoint changes where logins go without anyone editing the routing table, and the failure is silent because the requests are still being answered, by the wrong home server.
- A realm suffix is present but the forwarding server has no route for it. What should happen?Local policy decides: the request is normally dropped or answered with an `Access-Reject (Code 3)`. The important part is what a catch-all route would do instead - it makes every typo routable to whichever operator sits behind the default, turning a fast, clear failure into a slow and confusing one.
- Can one server be a forwarding server and a remote server at the same time?Yes, and it is the normal case. RFC 2865 section 2.6 describes positions in an exchange, not fixed roles for a machine. A host decides locally for the realms it serves and forwards the rest, so it is a remote server for one request and a forwarding server for the next.
saying these in an interview costs you the question
- The realm in User-Name (1) is a ticket-authentication realm
- A forwarding server also decides the login itself
- A name with no suffix can never be proxied
- The next hop is derived from the shared secret
- A server is permanently either forwarding or remote