Micro-segmentation in Proxmox with ProxWall
General
Micro-segmentation in Proxmox has become one of the most common topics in almost every customer conversation I have. Whenever companies migrate from other virtualization platforms they immediately ask for a unified and simple way to create secure network segments directly inside Proxmox. Until now this kind of solution simply did not exist but ProxWall might…
It reminded me a lot of the early days of my ProxLB project (fully open-source) when people were desperately looking for a real dynamic resource scheduler to balance their VM workloads across their clusters. That gap was wide open so I built ProxLB to solve exactly that problem.
Today I am filling another gap with ProxWall. It brings a clean centralized web interface and all the features users already know from other platforms so they can integrate micro segmentation into their Proxmox environments without changing the way they work.
ProxWall is designed to feel natural for Proxmox users and to deliver the tooling that many have been waiting for.
Table of Content
What is Micro-Segmentation?
Micro segmentation has become one of the core building blocks of modern infrastructure security. Instead of treating the data center as one large trusted network, micro segmentation breaks it down into many small isolated zones. Each zone contains only the workloads that actually belong together and all communication between zones is controlled through clear policies.
The idea behind this approach is simple. If an attacker manages to compromise one system, they should not be able to move freely inside the network. Micro segmentation limits the blast radius by enforcing the principle of least privilege at the network level. Workloads, even if they run on the same hypervisor or cluster, are only allowed to communicate with the exact services they require and nothing more.
In large virtualized environments this becomes especially important. Virtual machines and containers are created, deleted or moved between hosts at high speed. Traditional static firewall concepts are not flexible enough to keep up with this dynamic nature. Micro segmentation solves this by attaching policies directly to workloads, groups or metadata instead of physical network boundaries. This allows security rules to follow the workload wherever it runs.
The benefits are clear. It increases security, improves compliance, simplifies audits and gives organizations far more control over how internal communication flows. At the same time it enables teams to structure their environments more cleanly. Development, staging and production can be isolated from each other. Tenant environments can be split without relying on heavy VLAN architectures. Sensitive services can be shielded from general traffic.
In the end micro segmentation is not just a security feature. It is a way to bring structure, predictability and resilience into modern infrastructure. It transforms flat networks into controlled environments where every connection has a defined purpose. For today’s virtualized and cloud inspired data centers it is no longer a nice to have but a fundamental design principle.
ProxWall as a Solution for Proxmox VE Clusters
Proxmox VE already provides a strong foundation for secure and managed networking. With firewall capabilities available on the cluster, node and VM level, many environments can already implement solid baseline security. However, organizations that require full micro segmentation quickly reach the limits of what the native tooling can deliver. The built in features are powerful but they are not designed to handle the complete spectrum of modern segmentation and inspection needs.
This is where ProxWall steps in. It builds directly on top of the official Proxmox API which means it works with the mechanisms that already exist inside Proxmox rather than reinventing them. By using the native firewall layers, guest tags, security groups and cluster wide rules, ProxWall ensures that the basics are always aligned with upstream Proxmox functionality. This creates a seamless experience for administrators who want micro segmentation without losing the simplicity and transparency of Proxmox VE.
At the same time ProxWall extends the platform with the components that are currently missing. Environments that require deep visibility or advanced filtering need more than stateless firewall rules. They need IDS capabilities for intrusion detection and anomaly monitoring. They need L7 inspection to understand and control application traffic. They need clear traffic and flow visualization to see how segments interact. ProxWall integrates these additional layers by adding the related open-source tools and brings them together under a unified and centralized interface.
The result is a solution that feels native but delivers enterprise level segmentation. It adapts to the Proxmox ecosystem, respects the existing network design and uses the official interfaces to enforce rules. On top of that it adds the intelligence and depth that many teams expect from modern micro segmentation solutions. Whether the goal is to isolate tenants, secure internal application paths or create fully controlled zones, ProxWall closes the gap and enables Proxmox VE clusters to operate at a higher security and visibility level.
ProxWall Components
ProxWall is built around a clear and modular architecture that makes the entire solution easy to deploy, operate and scale. It consists of three main components:
- Management Interface
- Server
- Agent(s)
Each part has a dedicated role and together they form the foundation of micro-segmentation for Proxmox VE clusters.
ProxWall – Management Interface
The Management Interface provides the user facing web interface. It can be installed through a Debian package on any Debian based system or run as a container image. While it is technically possible to install it directly on a Proxmox node, we strongly recommend using a dedicated system. This can also be a high availability VM running inside the cluster to keep the management layer isolated and resilient. A Helm chart is currently under development to make deployment in Kubernetes clusters just as straightforward. The Management Interface communicates exclusively with the Server through an API and does not interact directly with Proxmox nodes. The web management interface is written in Flask/Python.
ProxWall – Server Component
The Server component follows the same deployment model. It is available as a Debian package and as a container image. It can run on its own or together with the Management Interface on the same host. The Server exposes a single API endpoint that acts as the central communication hub for the entire system. Both the Management Interface and all Agents connect to this API, making it the core of rule distribution, task handling and data collection. The server component is written in GoLang and comes as a single binary.
ProxWall – Agents
The Agents are installed directly on each Proxmox node. They connect to the Server through the API, retrieve tasks and configuration updates and report back metrics, state information and visibility data. This ensures that every node in the cluster actively participates in the micro segmentation process and always receives the latest policies. The Agents act as the bridge between ProxWall and the underlying Proxmox infrastructure. The Agent component is written in GoLang and comes as a single binary.
ProxWall Features
ProxWall delivers powerful micro segmentation and security tooling for Proxmox VE clusters, giving you full control over traffic and policies across the entire environment. The feature set covers everything from firewalling and networking to dynamic security groups, monitoring, authentication and Zero Trust concepts, providing strong protection from the cluster level down to each VM, including each virtual NIC of the VM object.
- Firewalling
- Affecting Levels
- Cluster
- Nodes
- VMs
- Rule sync over all PVE Nodes
- North-South Traffic Support
- East-West Traffic Support
- VM Virtual NIC Level Support
- Affecting Levels
- Networking
- Physical NICs
- VLAN
- VxLAN
- SDN
- Overlay Networks
- IPv4 & IPv6 Support
- Security Model Presets
- Zero-Trust
- Relaxed
- Log only
- Security-Groups
- Dynamic Grouping
- Pool based
- Tag based
- OS based
- Currently only Windows or “other”
- Static Grouping
- Dynamic Grouping
- Layer-7 Filtering
- WIP (Work in Progress)
- Monitoring
- IDS Integration (Suricata)
- Bandwidth Monitoring & Alerting
- Flow Monitoring & Alerting
- Authentication
- Internal Authentication System
- PVE Authentication Realm
On top of all these features, ProxWall can be fully themed and is available as a complete white-label solution, allowing you to adapt the interface and branding exactly to your environment or your customers’ needs.
Current State
The current state of the ProxWall project is still very much work in progress. We originally started this journey as a team of four developers, but life sometimes takes unexpected turns. A few major personal changes within the group made it impossible for some to continue contributing, so at the moment it’s just a friend and me actively pushing this project forward.
The project is in an early beta phase and many components are still evolving. Even the working title “ProxWall” is not guaranteed to be the final name. We are experimenting, improving and validating every layer to make sure the foundation is absolutely reliable before we take the next step.
There is currently no public release available. The impact of mistakes in this area is far too high. Anything touching the networking layer in a Proxmox cluster must be trusted blindly because a single misconfiguration could potentially take an entire datacenter offline. Before we publish anything, we want to be one hundred percent confident that the base mechanics are solid rock stable. Once we reach that point, we will start sharing updates.
If this sounds interesting to you, I will share some more insights and technical details about this at the 2nd Virtualization Gathering at credativ GmbH. Keep in mind, within the next one, I’m providing a talk about my BoxyBSD project and the underlying infrastructure including the decisions of the selected hypervisor.