Switches in a branch authenticate 802.1X users against Cisco ISE in the data center, and a new firewall was just placed between the two. Authentication and accounting both stopped working. Which firewall rule restores the standard RADIUS exchange?
Select an answer to reveal the explanation.
Short Explanation
Every protocol has its own front door, and RADIUS uses UDP 1812 for authentication and UDP 1813 for accounting. If the new firewall only knows TACACS+ or the wrong transport, the knocks never reach ISE. The classic trap you'll see is mixing up TACACS+ on TCP 49 with RADIUS on UDP, so make sure you open the right ones.
Full Explanation
RADIUS is a UDP protocol. The IANA-assigned ports are UDP 1812 for authentication and authorization and UDP 1813 for accounting, so a firewall inserted on the path must permit both from the network access devices to the policy service nodes, along with return traffic, which a stateful firewall handles automatically. Permitting TCP 49 is the TACACS+ port used for device administration; it does nothing for RADIUS-based 802.1X. Permitting only UDP 1645 refers to an older, pre-standard authentication port that some devices still default to; it is not the accounting port, so even where it is in use, accounting on 1646 or 1813 would still fail. Opening TCP 1812 and 1813 uses the wrong transport: classic RADIUS does not run over TCP, and reliability comes from client retransmission timers rather than from TCP. Exam caveat: TACACS+ uses TCP 49 and encrypts the whole payload, while RADIUS uses UDP and encrypts only the password field; port and transport questions often hinge on that contrast. Operational check: confirm which ports the switch is actually configured to use, permit those UDP ports through the new firewall, then use the firewall connection table or packet capture to see RADIUS requests and responses flowing and confirm ISE live logs show new authentications and accounting starts.