In RADIUS, which three reply codes can answer an Access-Request, and what does each one mean?
answer
- three answers, not two
- one answer is not final
- accept, reject, challenge
- a challenge wants another request
- Codes 2, 3 and 11
basics
~10 sA RADIUS server answers an Access-Request with Access-Accept (Code 2), Access-Reject (Code 3) or Access-Challenge (Code 11). Accept and reject end the exchange; a challenge asks for more input and expects a further Access-Request.
solid answer
~40 sA network access server packs a login attempt into an `Access-Request` (Code 1) and sends it over UDP, by default to port 1812. Exactly one reply comes back, and it carries one of three codes. `Access-Accept` (2) grants the attempt, and any attributes it carries configure the session the device is about to allow. `Access-Reject` (3) refuses it. `Access-Challenge` (11) is the interesting one: it is not a verdict at all, but a request for more input, and the exchange continues with another `Access-Request`. That third code is what makes anything beyond a single password possible. Note also that a timeout is not a reply — a refusal is always an explicit packet.
go deeper
Recall the three codes and their names: Access-Accept, Access-Reject, Access-Challenge. Be able to say which one does not end the exchange, and that the request itself is an Access-Request over UDP.
Explain why a challenge exists — it is the protocol's only multi-step shape — and what the device must do with one. Know that a device unable to challenge must treat it as a rejection.
Show that you treat a timeout as a fourth, ambiguous outcome rather than a refusal, and that you can separate the access exchange on 1812 from the accounting exchange on 1813 when reading a capture.
The angle a lead owns is what depends on this three-answer shape: any authentication method richer than one password needs the challenge round trip, so removing or blocking it quietly caps what the estate can ever require of users.
## What an Access-Request is A **network access server** — the switch port, wireless access point or remote-access concentrator that a user is trying to get through — does not decide a login by itself. It packs the credential and the circumstances of the attempt into an **`Access-Request` (Code 1)** and sends it as a UDP datagram to a RADIUS server, by default on **port 1812**. (The accounting half of the protocol uses **port 1813**; **1645** is a historic assignment that conflicted with another service and is still seen on old equipment.) Everything the device does next is driven by the single reply that comes back. There is no stream of progress messages, and no separate authorization query: one request, one reply. ## The three replies | Code | Name | What it tells the device | Exchange finished? | |---|---|---|---| | 2 | `Access-Accept` | The attempt succeeded; attributes in the packet configure the session about to be allowed | Yes | | 3 | `Access-Reject` | The attempt is refused; the device denies access | Yes | | 11 | `Access-Challenge` | The server cannot decide yet and wants more input | **No** | - An **`Access-Accept`** is permission *and* configuration. The device is expected to apply whatever the packet carries — a timeout, an address, a filter name — not merely to open the door. - An **`Access-Reject`** is a complete answer. It may carry displayable text, but it never carries session configuration, and there is no partial or conditional form of it. - An **`Access-Challenge`** is the only reply that does not end anything. It says: *I need one more thing from you before I decide.* ## Why a challenge exists at all Without Code 11 the protocol could only ever ask one question and get one answer, which would limit it to a single password presented up front. The challenge round trip turns the exchange into a conversation: 1. The device sends an `Access-Request` with what it has. 2. The server answers `Access-Challenge`, typically carrying a `Reply-Message` (18) to display and a `State` (24) value that the device must hand back. 3. The device collects the extra input and sends a **new** `Access-Request` — a fresh packet, not a retransmission — echoing `State` unchanged. 4. The server finally answers `Access-Accept` or `Access-Reject`, or challenges again. This is the only multi-step shape RADIUS has, and everything that needs more than one exchange rides on it. One consequence catches people out: a device that does not implement challenge/response is required to treat an `Access-Challenge` as though it were an `Access-Reject`. The user simply sees a failed login, with a perfectly healthy server on the other end. ## The accounting pair is a different exchange The same protocol carries a second, separate exchange: **`Accounting-Request` (Code 4)** answered by **`Accounting-Response` (Code 5)**, on UDP port **1813**. These record that a session started, is running or has ended. They are not part of the access decision, they travel to a different port, and an `Accounting-Response` is a bare acknowledgement rather than a verdict — so it is never the answer to an `Access-Request`. Codes **12** (`Status-Server`) and **13** (`Status-Client`) were reserved as experimental; `Status-Server` was later specified as a way to probe whether a server is alive. ## What a timeout is not Because the transport is UDP, the honest fourth outcome of any attempt is *nothing at all*. That is not a fourth reply code: - A refusal is an explicit `Access-Reject` packet. Silence never means denied. - The protocol defines no error or negative-acknowledgement packet, so a server that dislikes a request — because it does not recognise the sending device, or the packet does not validate — discards it without answering. - A lost `Access-Accept` and a lost `Access-Reject` look identical from the device's side, which is why the client has to retransmit rather than conclude. - Because the transport is connectionless, the device also learns nothing from the act of sending: there is no handshake to fail, so an unreachable server and a healthy one behave identically up to the moment a reply is due. That is why a device's timers matter as much as the codes. The reply is the only signal the protocol gives, the four header fields are the only thing tying it to the request that earned it, and everything else the device believes about the exchange is inference. A candidate who can name the three codes, say which one continues the conversation, and add that silence is not one of them has answered this question completely.
- What must a network access server do with an Access-Challenge if it cannot handle one?RFC 2865 requires a device that does not implement challenge/response to treat an `Access-Challenge` as though it had received an `Access-Reject`. The user sees a plain login failure, so a server that starts challenging a device that cannot answer turns working logins into unexplained refusals with nothing wrong at either end.
- Which codes carry the accounting half, and where do they go?`Accounting-Request` (Code 4) answered by `Accounting-Response` (Code 5), sent to UDP port 1813 rather than 1812. It is a separate exchange from the access decision: the response is a bare acknowledgement that the record arrived, not a verdict on anything, and it never answers an `Access-Request`.
- Can an Access-Reject carry anything useful to the user?It can carry a `Reply-Message` (18) for the device to display, which is how a server explains a refusal in words. What it never carries is session configuration: there is no partially-accepted outcome, so a device that finds attributes on a reject has nothing to apply them to.
saying these in an interview costs you the question
- Says an Access-Challenge means the login was denied.
- Thinks a server refuses a login by not answering it.
- Believes accept and reject are the only two possible replies.
- Calls Access-Challenge a retransmission of the same request.
- Expects an error packet when the server dislikes a request.