Appliance Firewall Requirements

Toggle the integrations you actually use to generate an ACL-like list for your implementation.

Integrations

CURRI / ECC API IntegrationⓘCDR ReportsⓘPhone Remote Control and DiscoveryⓘCUBE XCCⓘE911 for Microsoft Teamsⓘ

Call Policy Apps

Call Blocking & PoliciesⓘMissed Call AlertsⓘLDAP AuthenticationⓘPostgreSQL CRM LookupⓘCustom Webhooksⓘ

Platform

Admin AccessⓘCT-AI (LLM provider)ⓘApplication UpdatesⓘApplication OS Updatesⓘ

SOURCE   DESTINATION                PROTO  PORT   NEEDED FOR
CT     → cucm-pub                   TCP    8443   CUCM AXL / RIS
CT     → cucm-subs                  TCP    8443   CUCM AXL / RIS
cucm   → CT                         TCP      22   CDR over SFTP
cucm   → CT                         TCP      80   CURRI / ECC API
CT     → cucm-pub                   TCP    2748   JTAPI / CTI
CT     → cucm-subs                  TCP    2748   JTAPI / CTI
CT     → Phone Networks             TCP      80   Phone web pages
admins → CT                         TCP     443   Admin HTTPS + SSH
admins → CT                         TCP    2222   Admin HTTPS + SSH
CT     → get.calltelemetry.com      TCP     443   Application updates
CT     → *.docker.io                TCP     443   Application updates
CT     → mirrors.almalinux.org      TCP     443   OS package updates
CT     → repo.almalinux.org         TCP     443   OS package updates
CT     → mirrors.fedoraproject.org  TCP     443   OS package updates
CT     → dl.fedoraproject.org       TCP     443   OS package updates
CT     → download.fedoraproject.org TCP     443   OS package updates

7 features · 16 rules

Reference: All hosts & ports

The Call Telemetry appliance is self-contained and does not require internet access for normal operation. However, user-initiated updates require outbound HTTPS (port 443) access to download container images and OS packages.

Air-Gapped Support

Licensed users can build offline update packages with Call Telemetry Appliance Manager. Community edition users require internet access for all updates.

Required External Hosts

Updates connect to these services:

• Call Telemetry - CLI install script and release downloads
• Docker Hub - Container images for Call Telemetry services
• AlmaLinux/Fedora - OS security updates and package repositories

Call Telemetry Hosts

Host	Port	Purpose
get.calltelemetry.com	443	CLI install script and release downloads (bundles, config files, version markers)

Docker Hub Hosts

Container image downloads use three separate Docker Hub endpoints. Allow all three hostnames for outbound TCP 443. Allowing only the registry hostname lets the initial connection succeed but can still block authentication or image layer downloads.

For Docker's current domain list, see Allowlist for Docker Desktop. Docker's official allowlist names production.cloudfront.docker.com for pull and push traffic; do not substitute the legacy Cloudflare hostname.

The appliance uses Docker Engine rather than Docker Desktop, so Desktop update, telemetry, and UI hostnames are not required for appliance updates.

Host	Port	Purpose
auth.docker.io	443	Issues anonymous or authenticated pull tokens
registry-1.docker.io	443	Serves image manifests and registry metadata
production.cloudfront.docker.com	443	Serves image layers after a signed redirect from the registry

Use hostname rules, not fixed IP addresses

Docker Hub and its content-delivery network use changing IP addresses. Configure firewall rules using the exact DNS hostnames above, preserve TLS SNI, and allow HTTPS redirects. If your firewall performs TLS inspection, Docker Engine must trust the inspection certificate; adding it only to a user's browser or shell certificate store is not sufficient.

During preflight, Failed host identifies a hostname found in Docker's error message. Required registry hosts lists every hostname needed for that image pull when Docker cannot isolate the failure to one endpoint.

Container Images Downloaded

Image	Purpose
calltelemetry/web	Backend API server
calltelemetry/vue	Frontend web UI
calltelemetry/traceroute	Traceroute service
caddy:2-alpine	Reverse proxy
bitnamilegacy/postgresql:14	PostgreSQL database
nats:2.11	NATS messaging
prom/prometheus	Metrics collection
grafana/grafana	Metrics dashboards

AlmaLinux Package Repositories

The appliance runs AlmaLinux 9, a RHEL-compatible distribution. OS updates use the standard dnf package manager to download security patches and system packages.

How AlmaLinux Mirrors Work

AlmaLinux uses a global mirror network with hundreds of servers distributed across multiple continents. When running dnf update, the system contacts mirrors.almalinux.org which redirects to the geographically closest mirror. This means firewall rules must allow access to both the mirror coordinator and the actual mirror servers.

Dynamic Mirror Selection

Because mirrors.almalinux.org redirects to regional mirrors (like mirror.example.edu or almalinux.mirror.host.com), strict hostname-based firewalls may need to allow wildcard patterns or use URL category filtering rather than explicit hostnames.

AlmaLinux Hosts

Host	Port	Purpose
mirrors.almalinux.org	443	Mirror redirector - routes requests to nearest mirror
repo.almalinux.org	443	Primary repository and vault for older versions

EPEL Repository Hosts

The appliance uses EPEL (Extra Packages for Enterprise Linux) from the Fedora Project for additional packages not included in the base AlmaLinux repositories.

Host	Port	Purpose
mirrors.fedoraproject.org	443	EPEL mirror redirector
dl.fedoraproject.org	443	EPEL direct downloads
download.fedoraproject.org	443	EPEL package downloads

Firewall Strategies for Mirror Access

Option 1: Allow specific hostnames - Works if your firewall resolves and caches DNS. Allow the hosts listed above plus any regional mirrors your system uses (check with dnf repolist -v).

Option 2: URL category filtering - If your firewall supports URL categorization, allow the "Software Updates" or "Operating System Updates" category.

Option 3: Proxy server - Route dnf traffic through an HTTP proxy that has unrestricted outbound access. Configure in /etc/dnf/dnf.conf with proxy=http://proxy.example.com:8080.

Minimum Outbound Hostname Allow List

Allow outbound TCP 443 from the appliance to these hostnames. No inbound rule is required for updates.

# Call Telemetry
get.calltelemetry.com:443

# Docker Hub
auth.docker.io:443
registry-1.docker.io:443
production.cloudfront.docker.com:443

# AlmaLinux
mirrors.almalinux.org:443
repo.almalinux.org:443

# EPEL (Fedora Project)
mirrors.fedoraproject.org:443
dl.fedoraproject.org:443
download.fedoraproject.org:443

Verify Docker Hub Access

Run these commands on the appliance. The registry check is expected to return HTTP 401; that response confirms DNS, TCP, and TLS connectivity to the registry before authentication.

getent ahosts auth.docker.io registry-1.docker.io production.cloudfront.docker.com

curl -sS -o /dev/null -w 'auth.docker.io HTTP %{http_code}\n' \
  'https://auth.docker.io/token?service=registry.docker.io&scope=repository:library/caddy:pull'

curl -sS -o /dev/null -w 'registry-1.docker.io HTTP %{http_code}\n' \
  https://registry-1.docker.io/v2/

sudo docker manifest inspect \
  caddy@sha256:5f5c8640aae01df9654968d946d8f1a56c497f1dd5c5cda4cf95ab7c14d58648 \
  >/dev/null && echo 'Caddy manifest reachable'

The manifest command verifies authentication and registry access without downloading image layers. A successful manifest check does not prove that the layer CDN is allowed. The update preflight therefore prints production.cloudfront.docker.com:443 in the required-host list when a Docker Hub image cannot be verified.

Related Documentation

• VMware Appliance Quick Start - Initial deployment and network requirements
• Appliance Upgrade Process - How to run appliance updates