Networking

To plan the firewall and network for OpenLM Platform, use these requirements for every deployment path.

How traffic reaches OpenLM Platform

OpenLM Platform exposes a single HTTPS (port 443) ingress endpoint. This is the only port that needs to be accessible from outside the cluster network. All communication from Brokers, Workstation Agents, Directory Synchronization Agents, and users accessing the web UI flows through this single endpoint.

HTTP to HTTPS redirect

Port 80 (HTTP) is also typically exposed on the ingress controller to redirect HTTP requests to HTTPS. No application traffic is served over HTTP.

The Kubernetes cluster, its nodes, infrastructure services, and internal networking can reside on a fully enclosed private network. OpenLM does not require any inbound access to the cluster internals from the outside, and no remote management exists. The only inbound exposure is the HTTPS ingress configured during deployment. The cluster does make outbound connections to public container registries to pull images (see Outbound traffic), but it never calls back to OpenLM.

Inbound traffic

All inbound traffic enters through a single HTTPS (443) ingress endpoint:

Source	Protocol	Port	Purpose
Broker	HTTPS	443	License server event collection. Installed on machines running license servers.
Workstation Agent	HTTPS	443	Workstation usage event collection. Installed on end-user workstations.
Directory Synchronization Agent (DSA)	HTTPS	443	Directory scanning and synchronization events. Installed on a machine with directory access.
OpenLM Web	HTTPS	443	Users accessing OpenLM Platform administration, dashboards, and reporting.

All agents and users connect to the same fully qualified domain name (FQDN) configured during deployment. No direct access to Kubernetes nodes, API server, databases, or any internal service is required from outside the cluster network.

Outbound traffic

The Kubernetes cluster requires outbound access only for pulling container images:

Destination	Protocol	Port	Purpose
public.ecr.aws/r3q3q2f4	HTTPS	443	OpenLM container image registry
docker.tyk.io	HTTPS	443	API gateway (Tyk) images
docker.io	HTTPS	443	Infrastructure container images (Redis, Kafka, MongoDB, MariaDB, PostgreSQL) and the API gateway's busybox init container

All three registries are required

The infrastructure services run from public Docker Hub images, and the API gateway runs from Tyk's registry, not from the OpenLM registry. An allowlist containing only public.ecr.aws leaves Redis, Kafka, MongoDB, MariaDB, PostgreSQL, and the API gateway in ImagePullBackOff, and the installation fails.

No other outbound connectivity is required from the cluster at runtime. OpenLM Platform does not communicate with any external OpenLM servers. It runs entirely within your network. If your environment uses an HTTP proxy or firewall allowlist, add the three registry endpoints (public.ecr.aws, docker.tyk.io, docker.io).

External integrations

OpenLM Platform can also integrate with external services such as ServiceNow. If such integrations are configured, outbound access to those endpoints is required too. Add any integration endpoints to the firewall allowlist as needed.

Tip

For air-gapped environments, container images can be pre-loaded into a private registry. Contact OpenLM for guidance on offline image distribution.

TLS certificates

The TLS certificate must be trusted by every machine that connects to OpenLM Platform, including agent machines, user browsers, and services inside the cluster that call back to the FQDN. Without trust, HTTPS connections fail.

See TLS certificates for full requirements, configuration steps, and a troubleshooting guide.

On-premises machines

In addition to the OpenLM Platform requirements described earlier, on-premises Kubernetes clusters require inter-node communication and management access.

Inter-node ports (all nodes)

The following ports must be open between all nodes:

Port	Protocol	Purpose
6443	TCP	Kubernetes API server
8472	UDP	Flannel VXLAN overlay network
10250	TCP	Kubelet metrics
51820	UDP	Flannel WireGuard (if activated)

Role-specific ports

The following ports apply to specific node roles:

Node role	Port	Protocol	Purpose
Control plane	80	TCP	HTTP ingress (redirect to HTTPS)
Control plane	443	TCP	HTTPS ingress (agents, UI, API)
Infrastructure	30432	TCP	PostgreSQL NodePort for Power BI and other external reporting tools

Network topology

The following constraints apply to the cluster network layout:

• All nodes must reside on the same layer 2 (L2) network or have full inter-node connectivity with no port restrictions between them.
• The control plane node is the ingress entry point. DNS must resolve to this node's IP address or to a load balancer in front of it.
• Administration access (SSH, port 22) is required on all nodes for management.

Outbound (provisioning)

During initial setup, nodes also need access to the following endpoints:

Destination	Purpose
public.ecr.aws/r3q3q2f4	OpenLM container images
docker.tyk.io	API gateway (Tyk) images
docker.io	Infrastructure container images (Redis, Kafka, MongoDB, MariaDB, PostgreSQL)
get.k3s.io	K3s installation script (K3s-based installs, including Platform as VM)
get.helm.sh	Helm binary download
openlm-helm.github.io	Umbrella chart sub-chart metadata, during the chart install step
pypi.org, files.pythonhosted.org	Python packages for the Ansible-based installer
AlmaLinux and RHEL mirrors	OS package updates (dnf)

After installation, the three container registry endpoints remain required so that nodes can pull images when pods are rescheduled or restarted. The rest are needed only during provisioning.

Private cloud (AWS)

On AWS, networking is handled through a virtual private cloud (VPC) with public and private subnets.

VPC layout

The AWS network uses these components:

Component	Detail
VPC Classless Inter-Domain Routing (CIDR)	/22 block (for example, 10.0.0.0/22)
Private subnets	3, one per availability zone, for EKS nodes and managed services
Public subnets	3, for load balancers and the network address translation (NAT) gateway
NAT gateway	1, for outbound internet from private subnets
S3 endpoint	Gateway endpoint for S3 access without NAT

Security groups

The following security group rules control traffic between the cluster and the managed services you use. A service that runs in the cluster, such as in-cluster Kafka, needs no security group rule:

Service	Allowed source	Port	Protocol
EKS API server	Configured CIDRs (eks_public_access_cidrs)	443	TCP
RDS SQL Server	EKS cluster security group	1433	TCP
MSK (Kafka), if used	EKS cluster security group	9096	TCP
ElastiCache (Valkey)	EKS cluster security group	6379	TCP

Ingress

External traffic (agents and users) reaches the cluster through an AWS load balancer in the public subnets, forwarding to the ingress controller in the private subnets on ports 443 and 80.

Outbound

Outbound traffic from the cluster uses the following paths:

• Workload nodes in private subnets reach the internet through the NAT gateway.
• Container images are pulled from public.ecr.aws/r3q3q2f4, docker.tyk.io, and docker.io through NAT.

Private cloud (Azure)

On Azure, networking uses a virtual network (VNet) with Azure Container Networking Interface (CNI) mode for AKS.

VNet layout

The Azure network uses these components:

Component	Detail
VNet CIDR	/22 block (for example, 10.0.0.0/22) providing 1,024 IP addresses
Networking mode	Azure CNI (each pod gets a VNet IP)
IP capacity	About 400 IP addresses for pods, nodes, and growth

Network sizing

With Azure CNI, every pod consumes an IP address from the VNet:

• About 29 pod IPs per node
• 6 to 7 nodes provide about 174 to 203 pod IPs
• About 143 running pods plus node IPs fit within a /22 block with room for growth

Ingress

External traffic enters through an Azure load balancer or Application Gateway on ports 443 and 80, forwarding to the AKS ingress controller.

Managed service connectivity

Azure SQL Managed Instance and Azure Cache for Redis are accessed over private endpoints or VNet integration. No public internet exposure is required for managed services.

Outbound

Outbound traffic from the AKS cluster uses the following paths:

• AKS nodes pull container images from public.ecr.aws/r3q3q2f4, docker.tyk.io, and docker.io.
• Configure the AKS outbound type and firewall rules to allow access to the three registry endpoints.