RADIUS CoA and Disconnect-Message Configuration Guide

Every network access control deployment eventually hits the same wall: a laptop is quarantined, the endpoint is remediated ten seconds later, and the user still has no network — because nothing told the switch to re-authorise the session. RADIUS Change-of-Authorization (CoA) and Disconnect-Message solve exactly that. They are the only standard mechanism that lets a RADIUS server push a new policy to an already-authenticated session, or tear it down, without waiting for the client to re-authenticate. This guide covers the packets, the vendor configuration needed to accept them, the FreeRADIUS commands to send them, and the debugging sequence for the quiet failures that make CoA look broken.

CoA vs Disconnect: two different packets

Both are defined in RFC 5176 as Dynamic Authorization Extensions to RADIUS and both arrive on UDP port 3799 by default, but they do different jobs.

CoA-Request (43)          push a new attribute set to a live session
Disconnect-Request (40)   tear the session down immediately
CoA-ACK / Disconnect-ACK  1800-range codes; the NAS confirms
CoA-NAK / Disconnect-NAK  indicates rejection, usually unknown session-id

A CoA can add a VLAN, apply a downloadable ACL, change a filter-id, or reduce the session timeout. Because it modifies a session that already exists, the server must identify it precisely — that is what the NAS-IP-Address, NAS-Port and (critically) Acct-Session-Id attributes are for.

Why session identification is the hard part

The NAS recognises the target session by matching the request against its internal session table. If you send only the username, most implementations reject with a NAK. The reliable key is:

NAS-IP-Address   = 10.10.10.50      (the switch, not the RADIUS server)
NAS-Port         = 50104            (from Accounting-Start)
Acct-Session-Id  = 0000A1B2C3D4     (from Accounting-Start)
User-Name        = alice            (helpful but not sufficient alone)

This is the reason CoA "sometimes works": a session-id captured from an accounting record is valid, a guessed one is not.

Enabling the listener on the NAS

! Cisco IOS / IOS-XE (Catalyst 9000 example)
aaa server radius dynamic-author
 client 10.10.10.200 server-key 7 CiscoCoAKey
 port 3799
 auth-type any

! verify
show aaa server radius dynamic-author

# ArubaOS-CX
radius-server host 10.10.10.200 key plaintext CiscoCoAKey
aaa authentication port-access dot1x authenticator ...
# the CoA listener uses the same shared secret / port 3799

The client statement is a whitelist: only the listed RADIUS server IP may send dynamic authorisation requests. Leaving it wide open lets any host on the management VLAN re-write user sessions, so treat it as a security control, not a convenience setting.

Sending CoA from FreeRADIUS

echo "User-Name=alice,Acct-Session-Id=0000A1B2C3D4,NAS-IP-Address=10.10.10.50,Tunnel-Type=VLAN,Tunnel-Medium-Type=IEEE-802,Tunnel-Private-Group-Id=120" \
 | radclient -x 10.10.10.50:3799 coa CiscoCoAKey

# disconnect the same session
echo "User-Name=alice,Acct-Session-Id=0000A1B2C3D4,NAS-IP-Address=10.10.10.50" \
 | radclient -x 10.10.10.50:3799 disconnect CiscoCoAKey

-x prints the full request/response exchange including the reply code, which is the fastest way to distinguish a NAK (your attributes are wrong) from silence (a firewall or ACL is dropping UDP 3799).

Debugging a silent CoA failure

! on the switch
debug radius
debug aaa coa
terminal monitor

! then check the session exists at all
show authentication sessions interface GigabitEthernet1/0/10
show authentication sessions | include Session-Id

Symptom                        Likely cause
radclient times out            UDP 3799 blocked or client not whitelisted
CoA-NAK "session not found"    wrong Acct-Session-Id or stale session
CoA-ACK but no change          attribute not honoured by the port profile
Works for some users only      session-id cached from an old accounting record
Nothing in debug               request never reached the NAS

Design notes

CoA is a push mechanism, so it depends on the server knowing where the session lives. In multi-NAS deployments that means the RADIUS server must store the accounting mapping, and any load balancer in front of the RADIUS servers must be stateful for port 3799 as well — a load balancer that only balances 1812/1813 is the classic reason CoA works in the lab and fails in production.

For the surrounding architecture, see FreeRADIUS EAP-TLS with wired 802.1X, the policy-set model in Cisco ISE policy sets, and the protocol comparison in RADIUS vs TACACS+. For Aruba deployments the same listener is used by ArubaOS-CX 802.1X and MAB roles.

FAQ

Q: Can I use a port other than 3799? Yes, but both ends must agree; 3799 is the RFC default and the only value most vendor defaults expect.
Q: Does CoA work for MAC authentication bypass sessions? Yes — MAB sessions have their own session-id and are re-authorised the same way, which is the standard way to move a guest device out of quarantine.
Q: What about RADIUS over TLS (RadSec)? CoA support over RadSec exists but is vendor-specific; most deployments keep dynamic authorisation on the classic UDP channel.

原文链接：https://www.rfc-editor.org/rfc/rfc5176.html