In RADIUS, which device acts as the client and sends the Access-Request, and where does the end user's laptop sit?
answer
- count the RADIUS speakers
- the subject is not a speaker
- who was configured with the server address?
- NAS-IP-Address names the asker
- enforcement happens at the port
basics
~20 sThe network access server - the switch, wireless access point or remote-access concentrator the user connects through - is the RADIUS client and sends the Access-Request. The user's laptop sends no RADIUS packet at all; it is the subject of the exchange.
solid answer
~40 sRADIUS has two speakers. The **client** is the infrastructure device the user is trying to get through - the specification calls it a network access server. It collects the claimed identity and the circumstances of the attempt, builds an `Access-Request (Code 1)` and sends it to the **server**, the central machine that reaches the identity data and decides. The server answers once, with `Access-Accept (Code 2)`, `Access-Reject (Code 3)` or `Access-Challenge (Code 11)`, and the access device enforces that answer at the port. The user's laptop is the subject, not a speaker: it hands a credential to the access device by whatever the medium provides and never sees a RADIUS packet. Attributes such as `NAS-IP-Address (4)` and `NAS-Identifier (32)` inside the request say which access device is asking.
go deeper
Remember the pair: the access device is the client, the central machine is the server, and the user's device speaks neither. Name the three packets a positive, negative and inconclusive answer use.
Explain the inversion rather than asserting it: the access device originates the request, so it is the client, while being a server to the user at the same moment. Say which attributes identify the asker.
Show where the split bites in operation - a capture taken on the wrong host, a hanging login from an unenrolled access device, two devices collapsed into one client entry behind a translated address.
The consequence worth owning is that the deciding party has no reach into the network it decides about. Every control you want mid-session has to be designed as something the access device will enforce.
## The two speakers, and the one that stays silent RADIUS defines exactly two roles for a login exchange. The **client** is the device the user is trying to get through: a switch port, a wireless access point, a remote-access concentrator, a broadband aggregator. The specification's own name for it is a **network access server**. The **server** is the central machine that holds or reaches the identity data and makes the decision. The end user's laptop, handset or headless sensor is the **subject** of the exchange and never a speaker in it. It presents a credential to the access device by whatever means the medium provides, and no RADIUS packet ever reaches it. At a three-day agricultural showground, a dozen visiting exhibitor organisations keep their staff credentials at home and will not hand them over. Nothing on site can decide a login, so every access device asks: 1. An exhibitor's laptop presents a credential to the access device it connected through. 2. The access device builds an `Access-Request (Code 1)` carrying the claimed identity and the circumstances of the attempt. 3. It sends that request to the RADIUS server address it has been configured with. 4. The server answers **once**: `Access-Accept (Code 2)`, `Access-Reject (Code 3)` or `Access-Challenge (Code 11)`. 5. The access device enforces that answer at the port. It does not re-decide it. ## Why the naming feels backwards Everyday speech puts the client on the end user's desk, so 'the RADIUS client' sounds like the laptop. It never is. The word is being used in the ordinary protocol sense - the party that originates a request to a service - and here the originator is infrastructure. Two things make the inversion stick: - The box the user can see and touch is the client; the thing they think of as the server is reached only by that box. - The access device is a *server* in its own right, to the user, at the same moment it is a *client* to RADIUS. Both names are true from different sides. The word travels badly across neighbouring protocols too. A client in a delegated-authorization protocol is an application; in the dynamic-authorization extension to RADIUS the two roles reverse, on a different exchange and a different port. Say which one you mean. ## What the request says about who is asking The server is answering about a user, but it decides in the context of the device that asked. The request carries both, and the access-device half is what a policy engine keys on. | Attribute | What it tells the server | |---|---| | `User-Name (1)` | the identity being claimed | | `NAS-IP-Address (4)` | the address of the access device that is asking | | `NAS-Identifier (32)` | a name for that device where an address is not enough | | `NAS-Port (5)` | which port on it the attempt arrived on | | `NAS-Port-Type (61)` | what kind of medium that port is | | `Calling-Station-Id (31)` | an identifier for the endpoint attempting to connect | ## Enforcement stays with the client The server decides; the access device enforces. Whatever the reply carries - a session limit, a filter name - is an instruction the access device applies locally to its own port. The server never touches the port, cannot see traffic on it, and learns nothing more about the session unless the access device chooses to tell it. This is the second half of the inversion and the part people skip: the deciding party has no reach into the network it is deciding about. Its entire influence over the session is the contents of one reply. ## Where this trips people in production - **Troubleshooting on the wrong host.** A capture taken on the user's laptop will never show a RADIUS packet, because there are none to show. The exchange runs between the access device and the server. - **Silence instead of a rejection.** A server with no client entry for the source of a request has no basis to answer it and drops it. A newly installed access device that was never enrolled produces a login that hangs rather than one that fails cleanly. - **Devices sharing one source address.** The server matches its client entry on the packet's source, so two access devices behind one translated address resolve to the same entry, even though `NAS-IP-Address (4)` inside the request still distinguishes them. - **Assuming the server can intervene mid-session.** Once the reply has been enforced, the login exchange is over; nothing in it lets the server change its mind later. - **Reading 'client' as the user.** Every capacity number on a RADIUS server is per access device, not per person, which is why a single busy access point matters more than a busy floor of laptops.
- Why does a RADIUS server ignore a request from an access device it has no entry for, instead of rejecting it?It has no client entry - no recognised source and no shared secret - for that sender, so it has no basis on which to answer and drops the packet. The symptom is silence rather than an `Access-Reject (Code 3)`, which is why adding an access device to an estate means enrolling it on the server as well as pointing it at the server.
- Two access devices sit behind one translated source address. What does that do to the server's view of them?The server matches its client entry on the packet's source address, so both devices resolve to one entry and one configuration. The `NAS-IP-Address (4)` and `NAS-Identifier (32)` attributes inside each request still say which device is asking, so policy can tell them apart, but the server's trust decision about the sender cannot.
- If the server decides, why does the access device need any local configuration about what a session may do?Because enforcement is entirely local. The reply carries instructions such as a session limit or a filter name, and the access device must already know how to apply them. Anything the reply does not specify falls back to the device's own defaults, so an accept with no attributes grants whatever that device grants by default.
A steward on a showground gate telephones head office to ask whether a visitor is expected, then opens or blocks the gate on the answer. The visitor talks only to the steward and never to head office.
saying these in an interview costs you the question
- The user's laptop is the RADIUS client
- The access point just relays the laptop's RADIUS packets
- The RADIUS server opens and closes the switch port itself
- Any device can query the server without being enrolled first
- Whoever started the login is the client, so the user