What the Private Cloud Core v4 Host Firewall Blocks by Default

A private cloud has two layers of exposure to think about: the workloads running on it, and the servers running the cloud itself. Most security guidance for OpenStack focuses on the first, using security groups to control traffic to instances. Private Cloud Core v4 adds a host-level firewall to every node in the cloud as a standard part of deployment. Inbound traffic on each node’s internet-facing interface is denied by default, with only rate-limited SSH open. Everything else is something you grant on purpose.

Here’s the gap this closes. A new cloud’s nodes run the OpenStack control plane, Ceph, and supporting services. If those nodes accept connections from anywhere on their public interface, every exposed service is something you have to track, patch, and defend from the first minute. Many teams handle this by adding a firewall layer after deployment, which leaves a window where the cloud is live and the policy isn’t.

In v4, the policy is part of the platform from the start. You begin from a closed position and open what you need.

What the Firewall Does by Default

The firewall is built on UFW and applied to every Private Cloud Core v4 node during deployment. Its behavior depends on which network interface traffic arrives on.

The External Interface Is Closed

On the external, internet-facing interface, inbound traffic is denied by default. The one exception is SSH, which is open out of the box and rate-limited to slow down brute-force attempts.

That means services on the nodes aren’t reachable from the internet just because they’re running. To reach them from your office, your VPN, or your CI system, you add those networks as trusted networks.

Internal Cluster Networks Are Trusted

The private networks that connect the nodes of your cloud are treated as trusted and allow all traffic. That includes the networks for control plane traffic, storage replication, compute, and overlay tunnels, along with private links to other Private Cloud Core clusters you’ve connected.

This is deliberate. OpenStack and Ceph services talk to each other constantly across these networks, and filtering them would add complexity and failure modes without much benefit. These networks already run on dedicated VLANs that belong only to your cloud. Our network architecture explainer covers how that isolation works.

There’s no middle tier. An interface is either the external interface, which is default-deny, or an internal cluster network, which is fully trusted.

The Management Network Is Restricted

The management network is handled more tightly than the other internal networks. Instead of trusting the whole management subnet, the firewall allows only OpenMetal’s designated management hosts on it. Everything else on that network falls under the default-deny policy.

OpenMetal Operational Access Is Separate

The firewall keeps two separate lists of trusted sources:

• Your trusted networks, which you manage in OpenMetal Central or through the API
• An OpenMetal-managed list that covers the access our team needs to operate and support the platform

The OpenMetal-managed list isn’t editable through Central. Keeping the two separate means changes you make to your own access can’t accidentally cut off support access, and the reverse.

How Trusted Networks Work

You grant access by adding source IP addresses or subnets to your trusted networks. There’s one behavior here that everyone managing the cloud needs to understand.

A Trusted Network Gets Access to Everything on the Node

An entry in your trusted networks isn’t a rule that opens one port. A trusted source gets unrestricted access to all ports and protocols on the node, not just the ones the firewall opens by default.

That makes trusted networks simple to manage, but it also means you should be selective:

• Add specific addresses or tight subnets, not broad ranges.
• Prefer the egress address of a VPN or bastion host over a whole office network.
• Treat each entry as granting full network access to the nodes, because it does.
• Remove entries when the people or systems behind them no longer need access.

If you need port-level control for a specific source, put a VPN or bastion in front of the cloud and trust only that.

Make Changes in Central, Not on the Node

You have root access to your nodes, so you can see the firewall’s state directly. On any node, ufw status verbose shows the current rules and default policy.

But don’t make lasting changes by editing the firewall on the node by hand. Manual edits take effect immediately, but they don’t persist. The trusted network lists are rebuilt from their managed source on the next deployment run or node reboot, so a manual change will quietly disappear. Changes that need to last belong in Central.

Managing Trusted Networks Through the API

If you manage access lists from a central source of truth, such as a configuration repository or a security team’s allowlist, you can apply them through the OpenMetal API instead of the Central UI. Private Cloud Core clouds on deploy suite v4.0.0 or later support a firewall endpoint.

Read the Current Configuration

GET /v1/deployment/cloud/{cloudId}/firewall returns:

• Your current trusted network list
• The cloud’s VLAN topology, read-only, including which VLAN is the external-facing one
• The status of the last apply

Replace the Trusted Network List

PUT /v1/deployment/cloud/{cloudId}/firewall replaces your trusted networks:

{
  "customer_whitelist": ["203.0.113.10", "198.51.100.0/24"]
}

A few behaviors to build around:

• It’s a full replace. The list you send overwrites the existing one. Always send the complete list you want, never just the additions.
• IPv4 only, up to 100 entries. Entries can be individual addresses or CIDR blocks.
• Applying is asynchronous. A successful response means the change was queued, not that it’s live. Poll the GET endpoint until the status reaches success or error.
• One job at a time. A 409 response means another job is already running for the cloud. Wait and retry.
• Eligibility is checked. The endpoint rejects clouds that aren’t Private Cloud Cores or that are below deploy suite v4.0.0.

The full-replace behavior suits an allowlist-as-code workflow well. Your repository holds the complete list, your pipeline sends it, and the cloud’s state always matches what’s in version control. Before you automate it, test the flow against the API sandbox, which we covered in Provisioning Bare Metal Through an API Without Opening a Ticket.

How the Host Firewall Relates to Security Groups

The host firewall and OpenStack security groups do different jobs, and you need both.

• The host firewall protects the cloud’s nodes. It controls who can reach the servers running OpenStack and Ceph.
• Security groups protect your instances. They control traffic to and from the VMs you run, with rules you define per instance or per group of instances.

Adding a trusted network doesn’t change your security groups, and a permissive security group doesn’t open access to the nodes. Our article on building zero-trust network security on OpenStack with microsegmentation covers how to design security groups for workload isolation.

Mistakes to Avoid

A few patterns cause most of the trouble with an allowlist like this:

• Trusting a broad or changing range. Office ISP ranges and home connections change, and broad ranges trust far more than you intend. Use fixed egress points you control.
• Sending a partial list through the API. Because PUT replaces the whole list, sending only the new entry removes everything else. Keep the complete list in one place and always send all of it.
• Assuming the change is live. A successful PUT response means the apply was queued. Wait for the GET endpoint to report success before testing access, and handle error in your automation.
• Fixing access by hand on a node. It works until the next reboot or deployment run, then disappears. Make the change in Central or through the API.
• Forgetting automation sources. Hosted CI runners often use shifting egress addresses. If your pipelines call the cloud from outside, route them through a fixed egress address you can trust.
• Treating the host firewall as workload protection. It protects the nodes. Your instances still need well-designed security groups.

A Practical Starting Policy

For a new Private Cloud Core v4, a sensible first pass looks like this:

1. Decide where administrative access comes from. Ideally that’s one or two fixed egress points, such as a VPN concentrator or bastion host.
2. Add those addresses as trusted networks in Central, or through the API if you manage access as code.
3. Add your automation sources. If CI/CD pipelines or configuration management call your cloud’s APIs from outside, add their fixed egress addresses too.
4. Leave everything else closed. Rate-limited SSH stays available as a fallback.
5. Review the list on a schedule. Remove entries for networks, vendors, or systems that no longer need access.
6. Design your security groups separately for the workloads you’ll run.

Who Benefits Most

This model fits teams that:

• Want the cloud’s own infrastructure closed to the internet from the first day
• Manage access from a central allowlist and want the cloud to match it automatically
• Answer to security reviews and need a clear, explainable access model for the infrastructure layer
• Work in security, financial services, or other environments where unexplained exposure gets flagged

Plan around it if you:

• Need port-level restrictions per source on the nodes themselves; trusted networks grant full access, so use a VPN or bastion in front
• Rely on IPv6 sources for administrative access; the trusted network list accepts IPv4 only
• Expect manual firewall edits on a node to persist; they won’t

The Short Version

In Private Cloud Core v4, the nodes running your cloud start closed and stay that way until you decide otherwise. Trust a few specific networks, manage the list in Central or as code, and keep security groups for your workloads.

If you want to see how this access model fits your security requirements, apply for a proof of concept or talk with our team. You can also explore our hosted private cloud or size a deployment with the private cloud pricing calculator.

Frequently Asked Questions

Does Private Cloud Core v4 include a firewall?

Yes. Every Private Cloud Core v4 node ships with a UFW-based host firewall applied during deployment. Inbound traffic on the external interface is denied by default, with only rate-limited SSH open.

How do I allow access to my private cloud nodes?

Add the source IP addresses or subnets as trusted networks in OpenMetal Central, or send the full list through the OpenMetal API’s firewall endpoint. Trusted sources get access to all ports and protocols on the nodes.

Why do trusted networks get access to all ports?

The trusted network list is a source-based allowlist, not a set of per-port rules. That keeps it simple to manage, but it means you should add only specific, necessary sources. For per-port control, place a VPN or bastion in front of the cloud and trust only that.

Can I edit the firewall directly on a node?

You can see its state with ufw status verbose, since you have root access. But manual changes don’t persist. The trusted network lists are rebuilt on the next deployment run or reboot, so make lasting changes in Central or through the API.

Is the host firewall the same as OpenStack security groups?

No. The host firewall protects the servers that run your cloud. Security groups control traffic to and from your instances. You manage them separately and need both.

Can I manage the firewall with automation?

Yes. The OpenMetal API includes GET and PUT endpoints for a Private Cloud Core’s firewall configuration on deploy suite v4.0.0 or later. PUT replaces the full trusted network list, accepts up to 100 IPv4 addresses or CIDRs, and applies asynchronously.