Portnox local TACACS+ server container/VM

In this topic, you will learn what is the Portnox™ local TACACS+ server software, its requirements, and where to find deployment, troubleshooting, and update instructions.

Overview

The Portnox local TACACS+ server receives TACACS+ messages from your NAS devices, communicates with Portnox Cloud over an encrypted TLS connection, and responds based on the policies defined in the Portnox Cloud Portal. The local TACACS+ server is not required to use Portnox Cloud, but it is required if you want to use the TACACS+ service with Portnox Cloud, since Portnox Cloud does not offer a cloud-only TACACS+ option the way it does for RADIUS.

The local TACACS+ server is available as a Docker container (recommended), in the public Docker repository as portnox/portnox-tacacs, and as OVA (Open Virtualization Appliance) and VHD (Virtual Hard Disk) images for virtual machines, downloadable directly from Portnox Cloud. The virtual machine version of the local TACACS+ server runs on a minimal Tiny Core Linux system that includes only the components required to operate the server, for security reasons.

For an overview of how the local TACACS+ server interacts with Portnox Cloud, see the following topic: How does the Portnox Cloud TACACS+ service work?.

Requirements

Important:
The local TACACS+ server authenticates NAS devices based on the source IP address of each connection, so it must receive connections on the host’s real IP address rather than a virtualized or translated one. For this reason, the Docker container must run with host networking. Docker Desktop on Windows and macOS runs containers inside a hidden virtual machine rather than directly on the host, so it cannot provide real host networking, and the same limitation may apply to some cloud services. Before choosing a Docker platform for the local TACACS+ server, confirm that it supports host networking.

The following are the recommended minimum resources when installing the local TACACS+ server, whether on a virtual machine or as a Docker container:

  • CPU: at least 1 vCPU
  • RAM: at least 1 GB
  • Internet connectivity
Warning:
The performance of a local TACACS+ server depends on how many requests it processes, which cannot be predicted in advance. At a minimum, a local TACACS+ server needs 1 CPU and 1 GB of RAM. This is enough for most customers, but actual results may vary. Customers should monitor the server’s performance and add more resources if needed to avoid overloading it.

Notes:

  • If the host machine runs additional containers or software, allocate resources accordingly.

  • To make sure the local TACACS+ server can reach Portnox Cloud, see the following topic: How to set up the firewall for the local TACACS+ instance to connect to Portnox Cloud.

  • To make sure the local TACACS+ server can accept incoming connections from your NAS devices, open the standard TACACS+ port, TCP 49, on your local network firewall only, between the NAS devices and the local TACACS+ server.

  • Do not place NAS devices behind a NAT relative to the local TACACS+ server, since the server identifies NAS devices by their source IP address, and a NAT would make several NAS devices appear identical. If you use a NAT, we recommend encapsulating traffic between your NAS devices and the local TACACS+ container inside a VPN tunnel to avoid NAT traversal issues.

Deployment

Updates

When a new version of the local TACACS+ server is available:

  • If you use a virtual machine, it updates automatically and you do not need to do anything. The virtual machine restarts during the update, so there may be a short service interruption.

  • If you use a Docker container running on a local Docker host, it does not update automatically, unless you also use the autoupdate container. The autoupdate container updates all Portnox Docker containers when new versions are available. Updating requires recreating the Docker container, so there may be a short service interruption.

  • If you deploy the Docker container in a cloud environment, you cannot use the autoupdate container, because it requires direct access to the local Docker engine, which these managed cloud services do not expose. You must update containers deployed this way manually by redeploying them with the latest image.