TACACS+ Port Numbers and Protocol Basics

TACACS+ uses TCP (Transmission Control Protocol) port 49 for all communication between a network device and the TACACS+ server. Unlike RADIUS, which uses separate UDP (User Datagram Protocol) ports for authentication (1812) and accounting (1813), TACACS+ carries authentication, authorization, and accounting on one TCP port. Open TCP/49 from your devices to the server, enable single connect mode where the platform supports it, and add TCP/300 if you move to TACACS+ over TLS.

The rest of this page covers what the glossary entries leave out: why TCP, what single connect mode does to your connection count, and how to write the firewall rule.

What Port Does TACACS+ Use?

TCP port 49. The IETF (Internet Engineering Task Force) documents TACACS+ (Terminal Access Controller Access-Control System Plus) in RFC (Request for Comments) 8907. It states the port in one line: “TCP Server port 49 is allocated by IANA for TACACS+ traffic.” The network device (router, switch, firewall, wireless controller) always opens the connection; the server only listens. There is no separate accounting port.

One registry detail trips people up. The IANA port registry (IANA is the Internet Assigned Numbers Authority) lists port 49 for both TCP and UDP under “Login Host Protocol (TACACS)”. The UDP entry is for the original TACACS protocol (RFC 1492), which TACACS+ replaced. TACACS+ uses TCP only. Do not open UDP/49 for it.

Why TACACS+ Uses TCP Instead of UDP

Because TACACS+ carries a conversation. An authentication exchange can take several round trips (username, then password, then a one-time code if the server asks for one). Per-command authorization, where the device asks the server whether each command is allowed, adds a request for every command an administrator enters. TCP gives that conversation ordered, acknowledged delivery, so both sides know when a message arrived and when it did not.

RADIUS (Remote Authentication Dial-In User Service) made the opposite choice on purpose. RFC 2865 explains that RADIUS runs over UDP so the client can manage its own retransmission timers and move to a backup server quickly. That suits subscriber authentication, where one request and one reply is the normal shape.

For device administration, TCP pays off in two places. A lost accounting record is a hole in the audit trail. Over TCP, a failed session is an event the device can detect and log; over UDP, it is a packet that vanished. Our post on TACACS+ accounting records covers what that means for an audit. The second is scope of protection. TACACS+ obfuscates the entire packet body using the shared secret (a key configured on both device and server), while RADIUS hides only the password attribute. Only the 12-byte TACACS+ header travels in the clear. RFC 8907 calls this obfuscation because it is not encryption; encryption proper arrived with RFC 9887, in the table below.

TACACS+ vs. RADIUS Port Numbers

Two notes on the table. The 1645/1646 pair predates the official RADIUS assignment and collided with another registered service, so RFC 2865 moved RADIUS to 1812; expect the old pair on older equipment. Port 300 is the TACACS+ over TLS 1.3 (Transport Layer Security) port defined by RFC 9887 in December 2025. It is kept separate so a firewall can tell protected sessions from classic ones by port alone. For how the three AAA (authentication, authorization, and accounting) protocols divide the work in an operator network, see RADIUS vs. Diameter vs. TACACS+.

Single Connect Mode

Single connect mode lets a device multiplex many TACACS+ sessions over one TCP connection, so it does not open a new connection for each one.

The reason it matters is in a definition. In RFC 8907, a session is one authentication sequence, one authorization exchange, or one accounting exchange. With per-command authorization, every command is its own session. Without single connect mode, both sides close the TCP connection at the end of the first session, so every command costs a handshake, an exchange, and a teardown. Multiply that by a network operations center and a fleet of automation scripts running show commands, and the churn shows up in server load and firewall state tables.

The negotiation is short. The device sets the single-connect flag (TAC_PLUS_SINGLE_CONNECT_FLAG in the packet header) in its first packet on a new connection. If the server sets the same flag in its first reply, the mode is established and the connection stays open. Sessions on it are told apart by the session ID in each packet header. RFC 8907 says the flag is only relevant in those first two packets. If either side does not set it, the connection closes at the end of the session as normal.

Two practical notes. On Cisco IOS and IOS-XE the mode is enabled with the single-connection keyword in the TACACS+ server definition; other platforms have an equivalent. A long-lived connection also has a cost. A firewall between device and server may drop idle TCP state after, say, 30 minutes. It will silently kill a connection the device still believes is open. The next login then stalls until the device times out and reconnects. If you run single connect mode through a firewall, set the firewall’s idle timeout longer than the device’s quiet periods.

Firewall and ACL Considerations

Permit TCP from your device management addresses to the TACACS+ server on destination port 49. That is the only flow TACACS+ needs.

The device (the network access server, or NAS, in protocol terms) always initiates. On a stateful firewall, one that tracks each connection, a single rule in that direction is enough; return traffic rides the connection state. On a stateless ACL (access control list), such as a router interface ACL, you also need the reverse entry. Permit TCP from the server’s port 49 back to the device addresses. Add the established keyword (or your platform’s equivalent) so only traffic on an existing connection matches. That reverse entry is the “both directions” firewall guides mean.

Three more that come up in practice:

• Standby servers. Include every TACACS+ server the devices are configured with, standby included. Failover is invisible until the primary is down, which is a poor moment to find the secondary was never in the rule.
• Port 300. If you are moving to TACACS+ over TLS (RFC 9887), add TCP/300 as a second rule and keep TCP/49 until the last device has migrated. Separate ports are what let you retire 49 cleanly.
• Source addresses. Match the source addresses to what the devices actually use. A device may source TACACS+ from an egress interface rather than its loopback (the always-up virtual interface most teams intend). It passes authentication for months, then fails the day a routing path changes.
• See it on your own device types. Walk through a device login, per-command authorization, and a failover between active-active servers with the Alepo TACACS+ Server. The session is run by an engineer, around your scenario.
• Book a Demo →
• Still at the design stage? Download the TACACS+ datasheet (PDF).

FAQs

Q1. What port does TACACS+ use?

TCP port 49. The device opens the connection to the server, and authentication, authorization, and accounting all travel over it. TACACS+ over TLS 1.3 (RFC 9887) uses TCP port 300.

Q2. Does TACACS+ use TCP or UDP?

TCP. The protocol carries multi-step exchanges and a request for every authorized command, so it relies on ordered, acknowledged delivery. The UDP/49 entry in the IANA registry belongs to the original TACACS, not TACACS+.

Q3. Is TACACS+ port 49 the same for authentication and accounting?

Yes. One port carries all three functions. RADIUS splits them: UDP 1812 for authentication and authorization, UDP 1813 for accounting.

Q4. Do I need to open port 49 in both directions on my firewall?

On a stateful firewall, one rule permitting TCP from the devices to the server on port 49 is enough, because return traffic is matched to the connection. On a stateless ACL you also need the reverse entry for replies from the server’s port 49.

Q5. What is single connect mode in TACACS+?

A negotiated mode in which a device keeps one TCP connection open and multiplexes many TACACS+ sessions over it. The device requests it with a header flag in its first packet; the server confirms in its first reply.