Open-source alternative to Nutanix Flow Network Security

Open-source alternative to Nutanix Flow Network Security: the short answer

If your Flow Network Security policies exist only because your estate runs the top NCI edition, which includes Flow, or because you bought the Security add-on for NCI Pro, a renewal or an AHV exit forces you to rebuild them somewhere else. For smaller estates, Proxmox VE's built-in firewall covers host and VM-level segmentation through rules, security groups and IP sets applied at datacenter, node and VM scope. For larger multi-tenant estates, OpenStack security groups, enforced through Neutron, give each project self-service control over filtering. Neither reproduces Flow's full policy model out of the box. Expect gaps in policy categorization, application-aware rules and traffic visualization, and confirm each gap with a test in your own environment before you commit.

Keep the segmentation decision separate from your storage and hypervisor decisions. Flow operates above the hypervisor, so you can move compute to Proxmox VE with Ceph, or to OpenStack, and still choose the segmentation model on its own merits. Before any cutover, export your current Flow ruleset into a documented inventory: every category, every allow and isolation rule, and the workloads each one protects. Ask Nutanix which export formats Flow supports, and confirm with your own administrators what can be exported in practice, because the inventory is the basis for every mapping you will do later.

Run the inventory against a pilot group of workloads and build the equivalent rules in a staging cluster. Test the intended allows and denies with real traffic paths, then repeat the tests during an HA failover, since a VM restarted on another node must keep its policy. Verify where each platform enforces its rules and how it logs dropped traffic, using the current documentation for your chosen version. Finally, record which Flow policies could not be matched, and decide whether to accept each gap, add a compensating control or keep the Flow-dependent workloads on a separate track until the gap is closed.

How Flow capabilities map to open-source options

This table maps each Flow Network Security capability to the Proxmox VE firewall and to OpenStack Neutron security groups with OVN. Read the "Gap" entries as areas where you need an external control or a process, and confirm every capability against the current release documentation before you write a policy design.

Flow capability	Proxmox VE	OpenStack Neutron and OVN
Per-workload microsegmentation	Firewall rules at datacenter, node and VM levels, with VM-level rules applied to each guest's network interface. Confirm rule evaluation order.	Security groups attached to each port with stateful rules. Confirm default ingress and egress behavior for your release.
Category-based rules	Partial: security groups and IP sets can group VMs by role, but membership is maintained by hand. Confirm whether any tag-driven grouping exists.	Partial: one security group per role approximates categories, and OVN port groups can match ACLs. Membership is still assigned by the operator.
Isolation between applications and environments	Separate bridges, VLANs or SDN zones combined with firewall rules between them. Confirm which SDN features your version provides.	Separate networks per project, with security groups and OVN ACLs controlling traffic between them. Confirm the ML2 driver in use.
Policy visualization across the estate	Gap: rules are viewable per level in the web interface, but no cross-cluster policy map is assumed. Build an inventory from exported configuration.	Gap: policies are visible through the API and CLI, but a topology view of allowed flows is not assumed in core Horizon. Confirm with your dashboard tooling.
Flow-level analytics and traffic monitoring	Gap: firewall log output and host logs are available, but flow analytics are not assumed. Plan an external flow collector or sensor.	Gap: security group logging depends on the backend driver and release. Confirm in the release notes, and plan external flow collection as well.
Host-level and external controls	Host firewalls on each node and guest firewalls complement VM rules. Physical firewalls and VLAN policy remain outside the hypervisor.	OVN ACLs and host firewalls on compute nodes complement port rules. Confirm how your deployment tool configures them.
Policy change control and automation	Rules are stored as configuration and managed through the API. Version and review them in Git, then confirm the automation path for your cluster.	Rules are managed through the Neutron API, CLI and infrastructure-as-code tools. Confirm provider support for your release.

Which platform fits your Flow policy set

Proxmox VE fits a hyperconverged estate that reuses Nutanix hardware and keeps management in one cluster. Flow policies are applied per workload, and the closest equivalent is the Proxmox VE firewall, which can be set at datacenter, node and VM level and uses security groups and IP sets as reusable objects. Ceph RBD provides the shared storage that guests need to move between nodes.

Cluster size: High availability needs at least three nodes for reliable quorum, shared storage for guests, redundant hardware and watchdog-based fencing, so check these before you plan cutover. The Proxmox VE High Availability wiki sets out the requirements.
Team skills: Your staff will operate Linux, the Proxmox web interface and Ceph in place of Prism. Ceph operations are the part teams most often underestimate.
Policy translation: Map each Flow category to a tag or a security group membership, then rebuild each rule as a Proxmox firewall rule. Confirm the rule syntax and logging behavior for the release you deploy (Proxmox VE 9.2 was released on May 21, 2026).
Subscription scope: Subscriptions are priced per socket per year. All tiers include the same features, and support entitlements differ.

Confirm with Proxmox and your own testing that the firewall rule count and per-VM rule evaluation meet your throughput and change-control needs before you retire Flow.

Proxmox VE firewall, OpenStack security groups and external options compared

Flow microsegmentation works across hosts, clusters and Nutanix-managed networks as one policy model. Each open-source option below covers part of that job, with different enforcement points, operating models and gaps. Pick the layer that matches where your workloads run, then test every policy before cutover.

Proxmox VE built-in firewall

The Proxmox VE firewall runs at the datacenter, host and VM or container level, with rules defined in the web interface and stored as configuration files on the cluster. It fits estates that already run Proxmox VE and want policies close to each guest without extra appliances. Confirm that your rule sets can be expressed as datacenter, host and guest-level rules, and that you can express Flow category or tag logic with security groups or aliases. Review how rules behave during node failover, since HA guests need their rules present on the node that restarts them. Flow categories do not map one-to-one, so write the mapping table before you import anything.

OpenStack Neutron security groups

Neutron security groups filter traffic at the instance port, and they are the natural equivalent when the target platform is an OpenStack private cloud. Rules are stateful and tied to projects, which suits multi-tenant estates where teams manage their own policies. Confirm how your Flow policies translate into security group rules, how many rules each project needs, and how default-deny behavior is set for new projects. Note that security groups do not replace a network-level firewall or a zero trust layer for traffic that never reaches a Neutron port. Plan this option together with the wider OpenStack operating model, not as a standalone feature.

Dedicated host or distributed firewall layer

A separate firewall layer, such as host-based nftables or iptables policy managed by configuration tooling, or an appliance-based firewall at the network edge, enforces rules outside the hypervisor. This option fits estates with mixed hypervisors or physical servers that Flow never covered. The trade-off is that you own rule distribution, change control and logging across every host, and you must prove the rules match intent. Confirm which firewall product your security team can operate, how policy changes are reviewed, and whether logs reach your SIEM. Expect a clear gap in per-VM tag-based grouping unless your tooling adds it.

Zero trust overlay for workloads

A zero trust overlay controls access by identity and workload rather than by subnet, so it can cover users, service accounts and hosts that sit outside the hypervisor. Options such as Pomerium, OpenZiti and NetBird address this need, and they complement hypervisor firewalls rather than replacing them for east-west traffic. Confirm which access paths need identity-based policy, how device posture is checked, and whether the overlay supports your protocols. Treat this as a decision about access control, not a like-for-like replacement for Flow's virtual machine segmentation.

Policy testing before cutover

Whichever layer you choose, export the current Flow policy set, list each rule with its source and destination groups, and build a test matrix of expected allowed and denied flows. Run the matrix in a staging cluster or a parallel VLAN before any production change, and record each result as evidence. Confirm that your test tooling can reach both sides of each rule, that deny rules are tested as well as allows, and that rollback steps are written down. Use the results to decide which Flow policies can be retired and which need a new owner.

Running Flow-free segmentation next to AHV during transition

Keep Flow enforcing on every AHV workload until its replacement tier is proven, and make that the first rule of the transition plan. Flow Network Security is included in NCI Ultimate and sold as a Security add-on for NCI Pro, so a team that already pays for it has a clear reason to keep it running. The sequence then depends on when that license ends. Confirm your NCI term end date and whether the Security add-on renews with it, because a lapse would remove enforcement from workloads that are still on AHV. Migrate tiers in the order of their dependencies, and retire Flow only after the last AHV workload in a security zone has moved or been re-protected.

The main risk is two policy sets that disagree. Flow rules are written against Prism categories and their own policy ordering, while Proxmox VE firewall rules sit at datacenter, node, and VM or container levels, and OpenStack security groups are stateful rules attached to ports. Pick one source of truth for each zone, keep the other side in default-deny or log-only mode, and export the Flow policy list before any edit so you can diff it against the new rules. Test each boundary with a small set of known flows, both allowed and denied, and record the results. Confirm the exact import and export options for your Flow version in Nutanix documentation before scripting anything.

Check the network boundary between the two environments before cutover. Identify every path that crosses from AHV to Proxmox VE or OpenStack, including database connections, backup traffic, identity and DNS, and management interfaces, and decide which side enforces each one. Where both sides filter the same flow, make the rules symmetric so that a return path is not dropped by one side. Ask your network team to confirm VLAN or overlay mappings, MTU, and routing on the shared links, and run a traffic capture during the parallel period. An illustrative case: if a web tier stays on AHV while its database moves to Proxmox VE, both firewalls must permit the database port in the same direction, or the application fails only after cutover.

Where the new firewall layer sits beside the rest of the suite

Flow policies rarely live alone. They depend on identity, logging, VM migration and backup networking, and each of those dependencies forces a decision before cutover. The cards below name the dependency and the choice it creates, so you can confirm each one in your own environment before rules move.

Identity behind rule ownership

Flow policies are often written against categories and tags that someone in your organization maintains. Proxmox VE handles administration through its own user management and permission model, so decide who owns firewall rule changes and whether those accounts come from a local realm or an external directory. Confirm which identity provider your administrators already use and whether it is available to the Proxmox VE cluster during an outage.

Firewall logs reaching the SIEM

Flow microsegmentation denials are often a source of evidence during incident reviews. Before cutover, confirm how Proxmox VE firewall logs are collected, forwarded and retained, and whether your SIEM ingests them without a custom parser. Decide who reviews dropped traffic and how long those records must stay available for your own audit obligations.

VM moves in Prism Central

Moving VMs from AHV to another platform changes their network identity and sometimes their MAC addresses. Rules written against Flow categories will not follow a VM automatically, so map each category to the matching Proxmox VE security group or OpenStack security group before migrating. Confirm the order of operations so that a workload is never moved into an environment where its old allow rules are missing.

Backup networks and their exceptions

Backup traffic often crosses segments that microsegmentation policies were never designed to permit. Confirm which backup servers, such as Proxmox Backup Server or your existing backup platform, need access to each protected group, and write those flows as explicit rules before any default-deny policy is applied. Test restore paths as well as backup paths, because restores frequently need traffic in the opposite direction.

Cluster management and fencing traffic

Proxmox VE clusters depend on reliable node-to-node communication for configuration sync and high availability. A rule set that blocks cluster or corosync-style traffic can look like a node failure. Confirm the networks that carry cluster traffic, keep them outside any restrictive group during testing, and check that management access survives a firewall misconfiguration.

How to test segmentation policies before cutover

This sequence turns Flow microsegmentation rules into a tested, documented set of Proxmox VE firewall rules or OpenStack security groups, so each application group moves only after its allowed and denied paths have been proven in a non-production cluster.

Export and categorize current Flow policies
Work with the security architect and the application owners to list every Flow security policy, its isolation and allow rules, and the categories (such as application tier, environment or compliance scope) they use. Record which VMs each category selects, the ports and protocols allowed, and any rules that exist only as exceptions. Keep the export in version control. The step is complete when every policy has a row showing its source, target, port and owner, and nobody on the team knows of a rule that is missing from the list.
Map each rule to a Proxmox VE or OpenStack equivalent
Translate each Flow category into Proxmox VE firewall rules at the datacenter, node or VM level, or into OpenStack security groups and rules, depending on the target platform. Flag every rule that Flow expresses in a way the target cannot match exactly, such as identity-based or category-based grouping that needs tags or security group references, and decide how to handle it. The output is a written mapping document that a second engineer has reviewed. Confirm each target feature and its current behavior against the vendor or project documentation for your version.
Build the rule set in a non-production cluster
Deploy the translated rules to a non-production Proxmox VE cluster or OpenStack project that mirrors the production tags, VLANs and VM roles. Keep the rules in configuration files or infrastructure code so each change is reviewed and reproducible. Confirm that every VM receives the intended rule set by checking the rules applied on each host or port group. Done means the staging rules match the mapping document line for line, with any deviations approved and recorded.
Run allowed and denied traffic tests
Write a test matrix with one row per source, destination, port and protocol, labeled as expected allow or expected deny. Run each test from the real source workload or a test instance placed in the same category, and record the result with a timestamp. Include tests for lateral movement between tiers, management paths and administrative ports. The step is complete when every row has a recorded result and every mismatch has either a fix in the rule set or a documented decision to accept it.
Review denied-traffic logs
Enable logging for dropped packets on the target firewall and confirm that denials appear in the log with the expected source, destination and rule reference. Review the logs with the application owners to find legitimate flows that were blocked, such as DNS, time sync, monitoring or backup traffic that Flow previously allowed implicitly. Add those flows to the mapping document and re-run the matrix. The output is a log review record showing that no unexplained denials remain for the tested groups.
Cut over one application group at a time
Choose the lowest-risk application group first and move its workloads to the target policy in a planned window agreed with the owners. Apply the tested rules, verify the allowed paths from production, and watch the denied-traffic logs for the first sessions. Keep Flow enforcement in place for the remaining groups until each one passes. The step is complete when the group's application checks pass and the owners sign off in writing.
Prepare and rehearse a rollback plan
Before each cutover, write down how to restore the previous Flow policy or the earlier firewall configuration, who can authorize the rollback, and how long the team will watch before it closes the change. Store the prior configuration and rule exports so they can be reapplied without reconstruction. Rehearse the rollback in the non-production cluster and confirm it restores the expected behavior. The output is a rollback record for each group, linked to its change ticket.
Document the final policy and retire Flow rules
After the last group passes, store the final rule set, the test matrix and the log review records together as the segmentation baseline. Remove Flow policies only after the team confirms that no group still depends on them and that the baseline has been reviewed. Schedule periodic re-tests whenever rules change, and note that compliance assessors will ask for this evidence, which DeployOpen can help prepare but auditors and certification bodies decide on. The step is complete when the baseline is approved and stored.

Questions buyers ask about replacing Flow

Does the Proxmox VE firewall do the same thing as Nutanix Flow?

No, not one for one. The Proxmox VE firewall gives you datacenter, node and per-VM or per-container rules, plus security groups and IP sets that you define in the web interface, which covers the core of a microsegmentation policy. Flow, included in NCI Ultimate and available as a Security add-on for NCI Pro, adds its own policy model, visualization and categorization tied to Prism. Expect to rebuild policies by hand or with scripts, and confirm with Proxmox documentation exactly which features your target version provides before you sign off on a mapping. Some Flow capabilities may not have a direct equivalent and need a compensating control.

What work does our team have to do to replace Flow policies?

Your team needs to inventory every Flow policy and the application flows behind it, map each one to Proxmox VE firewall rules or security groups, and decide which rules belong at the datacenter, node or guest level. You also need to define the IP sets and aliases the rules depend on, build a test plan, and document who approves changes after cutover. Network and security engineers usually do the mapping, while application owners confirm the traffic each service needs. Plan time for the rules that were never documented, because those are the ones that break in testing.

How long does testing Flow policies take as the policy count grows?

The duration depends on policy count, how many application tiers are involved, and how much traffic must be observed before cutover. No researched figure is available for this, so ask any implementer for a timeline tied to your own policy inventory. A practical approach is to test in a non-production cluster first, run each policy group in logging or permissive mode where the platform supports it, and then enforce in stages by application tier. Scope testing per tier so the effort grows with the number of distinct flows, not with the total number of VMs.

What drives the cost of replacing Flow with open-source firewall rules?

The main cost components are staff time for mapping and testing, the skills needed to run Proxmox VE networking, any external testing, and support. Proxmox VE subscriptions are priced per occupied physical CPU socket per year: Community at 120 euros, Basic at 370 euros, Standard at 550 euros and Premium at 1,100 euros, according to the Proxmox VE pricing page. Every tier includes the same features and differs in support tickets, response time and enterprise repository access, and the software can run without a subscription. Ask any quote to separate one-time migration work from recurring subscription and support fees.

Which support tier should we choose for Proxmox VE during a Flow replacement?

Choose the tier by how much vendor help you expect during the migration and the production period that follows. The Proxmox VE pricing page lists Community with no support tickets, Basic with 3 tickets and a 1 business day response, Standard with 10 tickets and a 4-hour response, and Premium with unlimited tickets and a 2-hour response. Because the enterprise repository requires a valid subscription key and is the recommended repository for production, production clusters typically carry a subscription. Confirm the tier and the number of sockets in your environment before budgeting.

Can DeployOpen plan and implement the Flow replacement in our infrastructure?

Yes. DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, and that includes firewall and network policy design on Proxmox VE. Engagements are normally fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen also runs security testing, including testing of policies before cutover, and prepares evidence for compliance assessments, though it does not issue audit reports or certifications. Ongoing support and continuous testing are available as retainers, and quotes follow from the written scope.

Which Flow features might we lose when we move to open source?

Start with the features you actually use: policy visualization, application categorization, and any Prism-integrated views or alerting that teams rely on daily. The open-source side covers rule-based filtering, groups, and aliases, but you should verify each Flow feature against the target platform rather than assume parity. Record every gap in a register with an owner and a compensating control, such as a dedicated monitoring tool or host-based filtering, so the loss is a decision rather than a surprise. Confirm the gaps with the Proxmox documentation and your implementer before cutover.

What a fixed-scope microsegmentation engagement covers

A fixed-scope engagement for this migration starts with a written policy inventory. DeployOpen works with your team to list every Flow Network Security category and policy in use, the VM groups they target, and the traffic each one allows or isolates. The output is a rule catalogue that maps each Flow policy to either a Proxmox VE firewall rule set (cluster, host and VM levels) or an OpenStack security group, depending on the target platform. Scope, deliverables and timelines are agreed in writing before any work begins, so the inventory size and the number of application tiers should be stated up front.

The target design step covers how the new rules are organized: which Proxmox VE firewall scopes or OpenStack security group structures replace each Flow category, how management and storage traffic such as Ceph replication stay outside guest policy, and where logging and exceptions are recorded. Your team supplies the application dependency knowledge, owners for each tier, change approval contacts and access to a non-production cluster. DeployOpen does not own your application behavior, so unknown flows should be listed as open items in the scope rather than assumed. A clear list of owners reduces rework during testing.

Testing and cutover support follow the same written scope. DeployOpen can run policy tests in a non-production environment, verifying allowed and denied paths for each application tier, then document results and rollback steps for the cutover window. Hardening of the firewall configuration and documentation of the final rule set are included as deliverables. Ongoing monitoring, upgrades and continuous testing are separate retainers. Ask any proposal to name the test cases, the evidence delivered, and who signs off on acceptance, since DeployOpen prepares controls and evidence but does not issue audit reports or certifications.

How DeployOpen delivers module replacement

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including the network security layer that replaces Nutanix Flow. For this topic, we map each Flow microsegmentation policy to Proxmox VE firewall rules or OpenStack security groups, then prove the rules behave as intended before any workload moves.

How we scope

Inventory every Flow policy, its source and destination categories, and the applications and ports it protects
Agree in writing which policies move to Proxmox VE firewall rules, which map to OpenStack security groups, and which are retired
Engagements are fixed-scope, with deliverables and timelines agreed before work starts, and no prices in this section
Confirm with Nutanix documentation which Flow features your NCI edition includes, so the scope reflects what you actually run

How we build

Translate each allow and deny intent into Proxmox VE firewall rules at datacenter, node and VM levels, with reviewed rule sets
Build a test environment that mirrors production segments so policies are checked before any cutover date is set
Document every rule with its owner, business purpose and the traffic flows it permits, so auditors can trace it
Where OpenStack is in scope, define security groups and confirm the networking layer the target platform uses

How we hand over

Deliver a policy matrix mapping each original Flow rule to its replacement, with test evidence for each row
Record cutover steps, rollback criteria and the order in which application tiers are moved
Provide runbooks for changing firewall rules, reviewing drift and adding new segments under change control
Train your administrators on the target tooling, and confirm which tasks remain with your own team

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover
Re-test rule sets after platform upgrades, such as moves between Proxmox VE major releases, to catch unintended changes
Keep documentation current as applications are added or retired, so the policy matrix stays accurate
Confirm with the platform vendor or project which support channel covers your production firewall and network components

Open-source alternative to Nutanix Flow Network Security