VorticPanel

Why the panel never needs a way in to your KVM hypervisors

How an agent that connects out to the control panel keeps hypervisors closed to the panel and the internet, and which ports still matter between nodes.

4 min read

A VPS control panel has to reach every hypervisor it manages: to create servers, open consoles, read usage and move servers around. The usual way is for the panel to connect in to each node, which means every hypervisor has a management port open to the panel, and often to the whole internet.

In VorticPanel the connection runs the other way: the agent on each node connects out to the controller, and everything travels over the connections it opens.

The trouble with inbound management ports

Each hypervisor holds dozens of customers' servers, yet the usual setup puts a listening service on every one of them. Every open port is a service to patch, configure and watch, and a flaw in it is a flaw on every node at once. You can limit the port to the panel's address, but that list has to be right on every node and updated when the panel moves. A node behind NAT, or on a network the panel can't route to, needs port forwarding or a VPN before the panel can manage it at all.

How the agent connects

The agent on a node opens an HTTPS connection to the controller (port 443 on a standard install), the same as a web browser would, and keeps it open. Over that connection:

  • the controller sends tasks: create, start, stop, reinstall, snapshot, move;
  • the node sends back results and live CPU, memory, disk and traffic figures;
  • consoles are set up. VNC only listens on the node itself (127.0.0.1). When a customer opens a console, the agent opens one more connection out to the controller for that session, and the controller relays the customer's browser to it.

Nothing on a node has to accept connections from the controller or the internet. Your firewall can drop everything inbound from the internet except what you use yourself, such as SSH from your office. The only inbound traffic the panel needs on a node comes from your other nodes, covered below. A node behind NAT or a strict firewall can be managed as long as it can reach the panel's address.

What the agent trusts

An outbound connection only helps if the other end is the real controller. The agent:

  • connects to the controller over TLS, at the panel's own address;
  • signs in with a per-node credential created when you enroll it, in a file only root can read;
  • keeps the controller's own key from the day it joins, and carries out only orders signed with it;
  • checks new agents against the release key: once a node runs a signed agent, it refuses unsigned ones.

Enrolling a node uses a token that works once and expires after 60 minutes.

The ports that still matter

These go between nodes, on a management network you choose:

Port For
TCP 22 Moving servers between nodes. The disk and memory go through SSH. The node installer sets up and starts an SSH server for this.
UDP 51871 Customers' private networks across nodes, inside an encrypted WireGuard tunnel, with each node's own key.
UDP 4789 Private networks (VXLAN) to and from a node that can't run the tunnel. Each node only accepts it from the nodes that share a network with it.

Keep these on a private network or VLAN between your nodes, not open to the internet. Backups go out from the nodes to your S3 storage, or through the controller to your SFTP server, and imports copy servers from old hypervisors over SSH, all outbound.

On the controller, browsers and nodes use 80 and 443, and you use SSH. Its installer puts on a host firewall that lets in those (plus ping, and DNS if PowerDNS runs there) and closes the rest.

A firewall to start from

On a node, the end result can be as simple as:

  • Inbound from the internet: SSH from your own addresses only, everything else dropped.
  • Inbound from the management network: TCP 22 and UDP 51871 from your other nodes (and UDP 4789 if a node can't run the tunnel).
  • Outbound: HTTPS to the controller, and HTTPS to your S3 backup storage if you use S3.

Customers' traffic to their own servers goes through the node's bridge, and each server's firewall rules run on the host, so traffic a customer blocks doesn't reach their server.

Related