The ZTNA gateway Docker container (ztna-gateway)

In this topic, you will learn what the ztna-gateway Docker container does, its requirements, how to deploy it, and how its update behavior works.

Overview

The ztna-gateway Docker container is a feature of Portnox Zero Trust Network Access (ZTNA). It is required for ZTNA with hosted or console resources, where it establishes a secure connection between user devices and those resources.

It is available in the public Docker repository as portnox/ztna-gateway. It has no virtual machine equivalent.

Requirements

  • The container can run on Linux, or on Windows or macOS via Docker Desktop, or in a cloud container service. If running in a VM environment, we recommend Linux for the best results, since Windows and macOS would require double virtualization.

  • On-premises hosts need the NET_ADMIN and NET_RAW Linux capabilities, access to the /dev/net/tun device, and specific IPv6 sysctl settings. These are included in the command generated by Portnox Cloud.

    Cloud container services can’t grant those capabilities. Azure works around this by setting the USERSPACE_NETWORKING environment variable to 1. Other cloud providers likely need an equivalent workaround.

  • Follow the firewall rules in the following topic: How to set up the firewall for Portnox Docker containers to connect to Portnox Cloud.

Deployment

You do not have to build the docker run command manually. When you create a gateway in Portnox Cloud, it generates the complete command for you, already filled in with the unique APIUSER, APIKEY, and GWID values for that gateway. For step-by-step instructions on creating the gateway and deploying the container for a specific platform and resource type, see one of the following topics:

Updates

  • 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.