You have configured it a dozen times. Server IP, shared secret, Test Connectivity, green check, move on. RADIUS is the protocol behind most VPN logins, every 802.1X port, and nearly every enterprise Wi-Fi association, and most of us treat it as a box that says yes or no.

This post opens the box. We will walk through what is actually in the packets, how the shared secret is used (it never crosses the wire), where your group membership comes from, why MFA pushes time out, and what the 2024 Blast-RADIUS vulnerability changed. By the end you should be able to read a RADIUS capture and know which side is at fault.

The 60-Second Version

RADIUS (Remote Authentication Dial-In User Service) is a client/server AAA protocol. Authentication and authorization are defined in RFC 2865, accounting in RFC 2866. It runs over UDP: port 1812 for authentication and 1813 for accounting. Older gear used 1645 and 1646, and you will still find those defaults in the wild.

Three facts that surprise people the first time they look closely:

• The RADIUS client is not the user. It is the network device the user connects to: your FortiGate, switch, or wireless controller. The user’s laptop never sends a RADIUS packet.
• Authentication and authorization arrive together. There is no separate authorization exchange. The Access-Accept carries the attributes (group, VLAN, timeout, IP) that decide what the user gets.
• Almost nothing is encrypted. Usernames, NAS details, and reply attributes travel in cleartext. Only the password field is hidden, and only with an MD5-based keystream.

The Cast

NAS stands for Network Access Server, a name left over from the dial-up era when the device was a modem bank. The term stuck, and it shows up in attribute names like NAS-IP-Address and NAS-Identifier.

Packet Anatomy

Every RADIUS packet has the same 20-byte header followed by a list of attributes:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Identifier   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                   Authenticator (16 bytes)                    |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Attributes (Type / Length / Value) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-

Packet codes you will actually see

The Shared Secret and the Authenticator

The shared secret is the only trust anchor in classic RADIUS. It is configured on both the NAS and the server, it is never transmitted, and it is used in three places.

1. Proving the reply is genuine

The NAS puts 16 random bytes in the Authenticator field of each Access-Request. This is the Request Authenticator. The server computes the Response Authenticator for its reply like this:

ResponseAuth = MD5( Code + Identifier + Length + RequestAuth
                    + Attributes + SharedSecret )

The NAS runs the same calculation when the reply arrives. If the result does not match, the reply is discarded. Only a party holding the secret could have produced that hash for that specific request.

2. Hiding the password (PAP)

With PAP, the User-Password attribute is not hashed. It is XORed with an MD5 keystream derived from the secret and the Request Authenticator, which makes it reversible by the server:

b1 = MD5( SharedSecret + RequestAuth )      c1 = p1 XOR b1
b2 = MD5( SharedSecret + c1 )               c2 = p2 XOR b2
...
User-Password = c1 + c2 + ...   (password padded to 16-byte blocks)

The server reverses the process and ends up holding the cleartext password. That is the reason PAP works with any backend: the server can bind to LDAP with it, compare it to any hash format, or hand it to an MFA service.

3. Signing the whole packet

The optional Message-Authenticator attribute (type 80) is an HMAC-MD5 over the entire packet, keyed with the shared secret. It was originally required only for EAP. Since 2024 it is effectively mandatory everywhere. More on that in the security section.

Attributes: Where Everything Lives

Attributes are simple TLVs: one byte of type, one byte of length, then the value. Because length is a single byte, one attribute holds at most 253 bytes of value. Larger payloads, such as EAP messages, are split across several attributes of the same type.

Vendor-Specific Attributes (VSAs)

The standard attribute space is one byte, so vendors get a single type (26) and nest their own attributes inside it, keyed by their IANA enterprise number:

Type 26 | Length | Vendor-ID (4 bytes) | Vendor-Type | Vendor-Length | Value

Fortinet’s enterprise number is 12356. Cisco is 9 and Microsoft is 311. The Fortinet VSAs you will use most:

This is the answer to a question almost everyone asks eventually: “How does the firewall know which group the user is in?” It does not look anything up. The RADIUS server decides, and says so with an attribute in the Access-Accept. A FreeRADIUS users entry that does this looks like:

manny   Cleartext-Password := "<lab-password>"
        Fortinet-Group-Name = "VPN-Users",
        Session-Timeout = 28800

If the attribute is missing, misspelled, or differs in case from what the NAS expects, authentication succeeds and the user still gets nothing. Keep that failure mode in mind.

Walkthrough: A VPN Login With a Token

Here is the full exchange for a remote access VPN user with a one-time password, from connect to accounting:

1. The user enters a username and password in the VPN client. The client sends them to the FortiGate inside the VPN protocol. No RADIUS yet.
2. The FortiGate builds an Access-Request: User-Name, the hidden User-Password, NAS-IP-Address, Calling-Station-Id, a fresh Identifier, and a random Request Authenticator. It goes to UDP 1812.
3. The server validates the password against its identity store. The user needs a second factor, so it replies with an Access-Challenge containing a State value and a Reply-Message such as “Enter token code”.
4. The FortiGate relays the prompt to the client. The user types the OTP.
5. The FortiGate sends a second Access-Request with a new Identifier, the OTP in the User-Password field, and the State value echoed back so the server can tie it to step 3.
6. The server validates the OTP and returns an Access-Accept with authorization attributes: Fortinet-Group-Name, Session-Timeout, Class, perhaps Framed-IP-Address.
7. The FortiGate verifies the Response Authenticator, matches the group, and brings the tunnel up.
8. The FortiGate sends an Accounting-Request (Start) to UDP 1813. The server acknowledges with an Accounting-Response. Interim updates and a Stop record follow over the life of the session.

Without MFA, steps 3 through 5 disappear and the first Access-Request is answered directly with an Accept or Reject. That is the entire protocol for a simple PAP login: two packets.

Authentication Methods: PAP, CHAP, MS-CHAPv2, and EAP

The “authentication type” dropdown on your NAS decides how the credential is packaged inside the Access-Request. It matters more than it looks, because each method constrains what the server must have stored.

How EAP changes the picture

With EAP (RFC 3579), the NAS stops being a participant and becomes a relay. The supplicant and the RADIUS server hold an EAP conversation with each other. The NAS wraps each EAP packet from the client into EAP-Message attributes inside an Access-Request, and unwraps each Access-Challenge from the server back to the client. A PEAP or EAP-TLS login is typically 8 to 12 round trips, with the State attribute holding them together.

With tunneled methods, the NAS cannot see the credentials at all. The TLS tunnel terminates on the RADIUS server. When authentication finishes, the server sends the session keying material to the NAS in the Access-Accept (the MS-MPPE-Send-Key and MS-MPPE-Recv-Key VSAs), and that is what Wi-Fi encryption keys are derived from.

Access-Challenge and MFA

There are three common ways a second factor rides on RADIUS, and they behave differently on the wire:

The push pattern is behind the most common RADIUS support ticket: “MFA works but I have to be fast.” The FortiGate default remote authentication timeout is 5 seconds. Raise it globally and on the server object:

config system global
    set remoteauthtimeout 60
end
config user radius
    edit "LAB-RADIUS"
        set timeout 60
    next
end

Accounting

Accounting is a separate exchange on a separate port (1813) and is entirely optional. The NAS sends an Accounting-Request and the server answers with an Accounting-Response. The Acct-Status-Type attribute says what kind of record it is:

Accounting is how a server knows who is online right now, and it has a second life as a single sign-on feed. A device that receives accounting Start records learns the username to IP mapping without the user authenticating again. FortiGate’s RADIUS Single Sign-On (RSSO) works exactly this way.

One detail worth knowing: in accounting packets the Authenticator is not random. It is an MD5 hash over the packet and the shared secret, so accounting requests are integrity protected by design.

CoA and Disconnect: When the Server Talks First

Everything so far is initiated by the NAS. RFC 5176 adds the reverse direction. The server sends an unsolicited request to the NAS on UDP 3799:

• Disconnect-Request terminates a session. Used when an account is disabled or a posture check fails.
• CoA-Request (Change of Authorization) alters a live session: move the port to another VLAN, apply a different ACL, force a re-authentication.

The session is identified by attributes such as User-Name, Acct-Session-Id, or Calling-Station-Id, and the NAS answers with an ACK or NAK. Two practical consequences: the NAS must be configured to accept these messages from the server, and firewall policy between them must allow the server to initiate traffic to the NAS on 3799. NAC designs that work in the lab and fail in production are often missing that rule.

Reliability: Life on UDP

UDP gives RADIUS no delivery guarantee, so reliability is the client’s job:

• If no reply arrives within the timeout, the NAS retransmits the same packet with the same Identifier and Authenticator. The server recognizes the duplicate and resends its cached answer instead of authenticating twice.
• After the retry limit, the NAS marks the server as unresponsive and fails over to the secondary. Primary and secondary must have identical secrets, client entries, and policy, or you get failures that only appear during an outage.
• A server that does not recognize the source IP of a request does not reply at all. From the NAS, an unknown client looks exactly like a dead server.

The last point explains why the source IP matters so much. If the FortiGate reaches the server through an IPsec tunnel or a different interface than you expected, the request arrives from an address the server has no client entry for. Pin it with set source-ip or the interface selection options on the server object.

Security: Blast-RADIUS and What Changed

RADIUS was designed in the 1990s, and its integrity protection rests on MD5 with a shared secret. In July 2024, researchers disclosed Blast-RADIUS (CVE-2024-3596). An attacker positioned between the NAS and the server could use an MD5 chosen-prefix collision to turn an Access-Reject into a valid Access-Accept, without knowing the shared secret. PAP, CHAP, and MS-CHAP over UDP or TCP were affected. EAP was not, because EAP already required Message-Authenticator.

The fix is to sign every packet. Clients and servers now include Message-Authenticator in all requests and replies, and reject packets that lack it.

What this means on FortiOS

FortiOS 7.2.10, 7.4.5, and 7.6.1 made Message-Authenticator validation mandatory for RADIUS over UDP and TCP. If your RADIUS server has not been updated to send the attribute, authentication breaks right after the firmware upgrade, typically with “Invalid secret for the server” or “No message-authenticator attribute”. The fnbamd debug shows it plainly:

__rad_chk_resp_authenticator-The Message Authenticator validation is mandatory now
__rad_chk_resp_authenticator-No Message Authenticator

The correct fix is on the server side: patch it and enable Message-Authenticator. Microsoft NPS, FreeRADIUS, and the major MFA proxies all shipped updates. If you cannot patch immediately, FortiOS provides a per-server override. Treat it as a temporary exception and track it:

config user radius
    edit "LAB-RADIUS"
        set require-message-authenticator disable
    next
end

Hardening checklist

• Use a unique, long, random shared secret per NAS. The secret is the only thing protecting the password field, and captured exchanges can be attacked offline.
• Require Message-Authenticator on both the NAS and the server.
• Keep RADIUS on a management network. Never send it across an untrusted path without a tunnel.
• Use RADIUS over TLS (RadSec, RFC 6614, TCP 2083) where both ends support it. It wraps the entire conversation in TLS with certificate authentication.
• Prefer EAP-TLS or a tunneled EAP method wherever the access technology allows it.
• Restrict server client entries to specific NAS addresses, never whole subnets.

See It Yourself on a FortiGate

Reading about it only goes so far. The following lab uses a FortiGate at 10.0.1.1 and a RADIUS server at 10.0.10.50. Replace the placeholders with your own values.

Step 1: Define the server and a matching group

config user radius
    edit "LAB-RADIUS"
        set server "10.0.10.50"
        set secret <shared-secret>
        set auth-type auto
        set nas-ip 10.0.1.1
        set source-ip 10.0.1.1
    next
end
config user group
    edit "VPN-Users"
        set member "LAB-RADIUS"
        config match
            edit 1
                set server-name "LAB-RADIUS"
                set group-name "VPN-Users"
            next
        end
    next
end

The config match block is the piece people skip. Without it, every user the server accepts is a member of the group. With it, only users whose Access-Accept carries Fortinet-Group-Name = VPN-Users match.

Step 2: Test from the CLI

diagnose test authserver radius LAB-RADIUS pap <username> <password>

A healthy result reports that authentication succeeded and lists the group memberships returned by the server. Swap pap for chap, mschap, or mschap2 to confirm which methods the server policy actually permits.

Step 3: Watch the exchange

Open a second CLI session and enable the authentication daemon debug before you run the test again:

diagnose debug application fnbamd -1
diagnose debug console timestamp enable
diagnose debug enable

You will see the request being built, the server it is sent to, the code of the reply, and every attribute that came back, including the VSAs. Turn it off when you are done:

diagnose debug disable
diagnose debug reset

Step 4: Confirm on the wire

diagnose sniffer packet any 'host 10.0.10.50 and (port 1812 or port 1813)' 4 0 l

One request out and one reply back is a working exchange. Requests out with nothing coming back means the problem is the path or the server’s client list, not the credentials.

Troubleshooting by Symptom

Quick Reference

Wrapping Up

RADIUS is a small protocol: a 20-byte header, a list of TLVs, and a shared secret doing all of the trust work. Once you know that the NAS is the client, that authorization rides in the Access-Accept, and that silence usually means the server does not recognize the sender, most problems sort themselves into a short list. Run the fnbamd debug once on a working login so you know what normal looks like. The next time it breaks, the difference will be obvious.