ufw that permits only what is documented here, and opens cluster ports per-peer on its own); the ports below are what you must additionally permit on any network between the appliance, its users, and its dependencies.
How to read the Direction column.
- Inbound — a connection to the appliance (from users, admins, or the VIP). Open it toward the appliance.
- Outbound — a connection the appliance initiates to a dependency (KMS, storage, mail, DNS). Open it from the appliance to that host.
- Inter-node — traffic between cluster nodes, initiated either way. Permit it bidirectionally across the nodes’ management subnet.
File content never transits the appliance. Uploads and downloads are presigned and go browser-direct to your S3-compatible object storage. This means your users’ browsers also need outbound
443/TCP (or your storage endpoint’s port) to the storage host — not just the appliance. It also means appliance sizing and port throughput are driven by metadata and API traffic, not file bytes.Standalone deployment
A single appliance publishes exactly one inbound port. Everything else is outbound to your own infrastructure.Inbound — to the appliance
Outbound — from the appliance
Open only the ones your configuration actually uses. All are initiated by the appliance.Object storage on a non-standard port. Self-hosted MinIO or a storage gateway
may listen on a custom port (for example
9000) — open that instead of 443 to
the storage host. The KMS/storage endpoints you enter in the admin UI define the
exact hosts and ports; keep the firewall aligned with them.Egress lockdown (optional, recommended)
The appliance’s outbound firewall defaults to allow. To move to default-deny egress — permitting only DNS, NTP, and the specific dependencies above — use the console:egress allow per dependency (storage, KMS, SMTP relay, LDAP, SSO, webhooks) using the tables above.
High-availability cluster
A cluster adds a floating VIP (the ingress your users reach) and inter-node traffic between the appliance nodes. Everything from the standalone tables still applies per node (each node still makes its own outbound calls to KMS, storage, mail, DNS, NTP).Cluster nodes must sit on the same Layer-2 subnet — the VIP is managed with
VRRP (keepalived), which is L2-only and uses multicast. Cross-site failover is out
of scope for the VIP; use DNS/GTM for disaster-recovery between sites.
Inbound — to the cluster (the VIP)
Inter-node — between cluster nodes
The appliance opens these automatically on its own host firewall, scoped to each peer’s exact/32. You must permit the same ports between nodes on any switch ACL, hypervisor security group, or subnet firewall that sits between them.
Redis and RabbitMQ stay node-local in the standard cluster, so they need no
inter-node ports. This is by design — real-time chat and presence are pinned to the
canonical ingress (the VIP) rather than replicated across nodes. No firewall action
is required for
6379, 26379, 5672, 25672, or 4369.TCP protocol summary (IP protocol 112 aside)
Every inter-node data-plane port is TCP. VRRP is the only non-TCP, non-UDP element and must be permitted as IP protocol 112.Quick verification
From the appliance console (or over SSH once enabled):Connection to <host> <port> port [tcp/*] succeeded.
Next steps
Network Configuration
Static IP, DNS, and NIC bonding for the appliance.
High Availability & Clustering
Build the VIP-fronted cluster these inter-node ports serve.
KMS Configuration
AWS KMS and Thales CipherTrust (the
443 / 5696 outbound dependencies).Storage Configuration
The S3-compatible endpoint your browsers and appliance reach directly.