> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kvelden.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Network Ports & Firewall

> Every port the on-premise appliance uses — inbound, outbound, and inter-node for high-availability clusters — with protocol and direction, so your network team can open exactly what is needed and nothing more.

This page lists every port the appliance uses so you can configure upstream firewalls, switch ACLs, and hypervisor security groups. The appliance manages **its own** host firewall automatically (a default-deny `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**.

<Info>
  **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.
</Info>

<Note>
  **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.
</Note>

## Standalone deployment

A single appliance publishes exactly **one** inbound port. Everything else is outbound to your own infrastructure.

### Inbound — to the appliance

| Port  | Protocol | Direction | Source                               | Purpose                                                                                                                                                     | Required |
| ----- | -------- | --------- | ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- |
| `443` | TCP      | Inbound   | Users' browsers / your reverse proxy | HTTPS web UI **and** API. The only port the appliance publishes.                                                                                            | **Yes**  |
| `22`  | TCP      | Inbound   | Admin workstations                   | SSH for console administration — **key-only, and disabled until you enrol a key and run `ssh-enable`**. Leave closed if you administer from the VM console. | Optional |

<Warning>
  The appliance ships with **no open SSH** and no password auth. Port `22` is opened
  only after you enrol an SSH public key and explicitly enable it. Do not open `22`
  on an upstream firewall unless you have enabled SSH on the appliance.
</Warning>

### Outbound — from the appliance

Open only the ones your configuration actually uses. All are initiated **by** the appliance.

| Port                 | Protocol  | Direction | Destination                              | Purpose                                                                                                | Required              |
| -------------------- | --------- | --------- | ---------------------------------------- | ------------------------------------------------------------------------------------------------------ | --------------------- |
| `53`                 | TCP + UDP | Outbound  | Your DNS resolver                        | Name resolution for all outbound hosts                                                                 | **Yes**               |
| `123`                | UDP       | Outbound  | NTP server (e.g. your domain controller) | Clock sync — required for KMS/TLS and licence activation                                               | **Yes**               |
| `443`                | TCP       | Outbound  | S3-compatible object storage             | Bucket operations (metadata, presign, lifecycle)                                                       | **Yes**               |
| `443`                | TCP       | Outbound  | AWS KMS endpoint                         | Key wrapping when using AWS KMS (BYOK/HYOK)                                                            | If AWS KMS            |
| `5696`               | TCP       | Outbound  | Thales CipherTrust Manager               | KMIP key wrapping when using CipherTrust (HYOK)                                                        | If CipherTrust        |
| `587` / `465` / `25` | TCP       | Outbound  | Your SMTP relay                          | Invitation and notification mail. AWS SES alternates: `2587` (STARTTLS), `465` / `2465` (implicit TLS) | If mail enabled       |
| `636`                | TCP       | Outbound  | LDAP/AD server                           | Directory sign-in over LDAPS (implicit TLS, recommended)                                               | If LDAP/AD            |
| `389`                | TCP       | Outbound  | LDAP/AD server                           | Directory sign-in over StartTLS (plaintext binds are rejected)                                         | If LDAP/AD (StartTLS) |
| `3268` / `3269`      | TCP       | Outbound  | Active Directory Global Catalog          | Multi-domain AD lookups (`3269` = LDAPS)                                                               | If multi-domain AD    |
| `443`                | TCP       | Outbound  | SSO identity provider                    | OIDC token/JWKS and SAML metadata fetch (server-to-IdP)                                                | If SSO                |
| `443` (or custom)    | TCP       | Outbound  | Your webhook receivers                   | Outbound event delivery to endpoints you configure                                                     | If webhooks           |

<Note>
  **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.
</Note>

### 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:

```bash theme={null}
egress lockdown                      # deny outbound except DNS, NTP, loopback, established
egress allow <cidr> <port>           # e.g. egress allow 10.20.0.0/24 5696  (CipherTrust)
egress status                        # show the active allow-out rules
egress open                          # restore default-allow
```

Add one `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).

<Info>
  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.
</Info>

### Inbound — to the cluster (the VIP)

| Port  | Protocol | Direction | Source             | Purpose                                                                                                                       | Required |
| ----- | -------- | --------- | ------------------ | ----------------------------------------------------------------------------------------------------------------------------- | -------- |
| `443` | TCP      | Inbound   | Users' browsers    | HTTPS to the **cluster VIP** — the canonical ingress. Each node also answers `443` on its own IP for per-node console access. | **Yes**  |
| `22`  | TCP      | Inbound   | Admin workstations | Per-node SSH — same key-only, opt-in rules as standalone.                                                                     | Optional |

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

| Port   | Protocol                                     | Direction  | Purpose                                         | Required |
| ------ | -------------------------------------------- | ---------- | ----------------------------------------------- | -------- |
| `2379` | TCP                                          | Inter-node | etcd client API (Patroni ↔ etcd, cross-node)    | **Yes**  |
| `2380` | TCP                                          | Inter-node | etcd raft peer traffic                          | **Yes**  |
| `5432` | TCP                                          | Inter-node | PostgreSQL replication + HAProxy leader routing | **Yes**  |
| `8008` | TCP                                          | Inter-node | Patroni REST API (health, topology, failover)   | **Yes**  |
| VRRP   | IP protocol **112** (multicast `224.0.0.18`) | Inter-node | keepalived VIP advertisements                   | **Yes**  |

<Warning>
  **Do not block VRRP (IP protocol 112).** It is a distinct IP protocol, **not** a
  TCP/UDP port, so port-based rules miss it. If VRRP adverts are dropped, every
  backup node believes the master is gone and **all nodes claim the VIP at once**
  (split-brain ingress). Many stateful firewalls and cloud security groups drop
  multicast/VRRP by default — explicitly allow it between the nodes.
</Warning>

<Note>
  **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`.
</Note>

### 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):

```bash theme={null}
# Outbound reachability to a dependency (example: CipherTrust KMIP)
nc -zv your-hsm-host 5696

# Inter-node reachability from one node to a peer (example: etcd + Patroni)
nc -zv <peer-node-ip> 2379
nc -zv <peer-node-ip> 8008

# Confirm the appliance's own firewall state
egress status
```

A successful check prints `Connection to <host> <port> port [tcp/*] succeeded`.

## Next steps

<CardGroup cols={2}>
  <Card title="Network Configuration" icon="network-wired" href="/enclave/appliance/network">
    Static IP, DNS, and NIC bonding for the appliance.
  </Card>

  <Card title="High Availability & Clustering" icon="server" href="/enclave/appliance/clustering">
    Build the VIP-fronted cluster these inter-node ports serve.
  </Card>

  <Card title="KMS Configuration" icon="key" href="/enclave/appliance/kms">
    AWS KMS and Thales CipherTrust (the `443` / `5696` outbound dependencies).
  </Card>

  <Card title="Storage Configuration" icon="database" href="/enclave/appliance/storage">
    The S3-compatible endpoint your browsers and appliance reach directly.
  </Card>
</CardGroup>