Into the Verlocx server

From	Port	Purpose	Needed
Users' browsers	`443/tcp`	Portal, REST API, browser console (/vnc)	Yes
Users' browsers	`80/tcp`	Redirect to HTTPS	Recommended
Guest VMs (agent)	`8787/tcp`	Agent connection to the backend (WebSocket over TLS)	Yes
Guest VMs (agent)	`443/tcp`	Agent self-updates (manifest + download from the portal)	For updates
Docker networks (172.16.0.0/12)	`5432/tcp`	Portal container → PostgreSQL on the host	Yes — only from Docker
Portal container (Docker network)	`8788/tcp`	Portal → backend: its connection and admin calls, with the portal's own secret	Yes — never published, no firewall rule

Out of the Verlocx server

To	Port	Purpose	Needed
Proxmox VE nodes	`8006/tcp`	API: clone, power, snapshots, backups, HA, console tickets	Yes
Proxmox VE nodes	`22/tcp`	SSH for LVM snapshots on raw LVM storage	LVM storage only
Linux guests	`22/tcp`	In-browser SSH console	If you use it
Domain controllers	389/tcp · 636/tcp	Directory sign-in, group lookups, removing computer objects on delete	With Active Directory
login.microsoftonline.com	`443/tcp`	Microsoft sign-in (Entra ID)	With Microsoft sign-in
Mail server	`587/tcp`	Lease warnings and owner notifications	With e-mail
vCenter	`443/tcp`	VMware vSphere API	In preparation

Guests to your domain (not Verlocx-specific)

Joining a VM to Active Directory needs the usual Windows domain ports from the guest network to the domain controllers:

Port	Service
`53 tcp/udp`	DNS
`88 tcp/udp`	Kerberos
`135/tcp + 49152–65535/tcp`	RPC endpoint mapper and dynamic RPC
`389 tcp/udp · 636/tcp`	LDAP · LDAPS
`445/tcp`	SMB
`464 tcp/udp`	Kerberos password change
`3268–3269/tcp`	Global catalog

ufw on the Verlocx server

shell

1ufw default deny incoming2ufw allow 22/tcp                                   # your own SSH access3ufw allow 80/tcp4ufw allow 443/tcp5ufw allow 8787/tcp comment 'verlocx backend (agents)'6ufw allow from 172.16.0.0/12 to any port 5432 proto tcp comment 'verlocx portal -> postgres'7ufw enable

Ports published by Docker (443, 8787) bypass ufw's incoming rules. Restrict them at your network firewall if only certain subnets should reach them — 8787 only needs to be reachable from the guest networks. The portal listener (8788) is never published: it stays on the Docker network between the portal and the backend.

Why the agent needs no inbound port

The agent always opens the connection, to the backend on 8787, and keeps it open. Commands travel back over that connection. Before trusting the server, the agent checks that it holds the private key matching the public key in its config — so a different host on that address can't take it over.

Verify the paths

From the Verlocx server — each should connect:

shell

1nc -zv pve01.example.com 8006        # Proxmox API2nc -zv pve01.example.com 22          # SSH (only for raw LVM snapshots)3nc -zv dc01.example.com 636          # LDAPS4nc -zv mail.example.com 587          # SMTP5docker exec verlocx_portal sh -c 'nc -zv host.docker.internal 5432'   # portal → PostgreSQL6docker exec verlocx_portal sh -c 'nc -zv verlocx_backend 8788'         # portal → backend (internal)

From a guest VM (PowerShell) — the agent's path to the backend:

PowerShell

1Test-NetConnection verlocx.example.com -Port 87872Test-NetConnection verlocx.example.com -Port 4433Test-NetConnection verlocx.example.com -Port 8788   # must FAIL — the portal listener isn't reachable from guests

Common blocks

Symptom	Cause
Portal log: `CONNECT_TIMEOUT host.docker.internal:5432`	`ufw allow from 172.16.0.0/12 to any port 5432 proto tcp`
Agents never come online	Guest networks → Verlocx server on 8787
Cluster connection test times out	Verlocx server → Proxmox nodes on 8006
Agent updates fail, everything else works	Guest networks → Verlocx server on 443
Portal log: `ECONNREFUSED …:8788`	The backend has no `portal_listen`, or wasn't restarted after the change — not a firewall rule.
Portal log: `Unexpected server response: 401`	`VERLOCX_PORTAL_SECRET` doesn't match the backend's `portal_secret`.

Firewall & ports