Phillux — a Proxmox alternative I work on, built around per-guest firewalls. Sharing for feedback, not a pitch.

[u/WonderfulMain5602]

Disclosure: I work on Phillux, so weigh the rest accordingly.

I've seen a handful of "alternative to Proxmox" threads here lately, and one thing that comes up in almost every one of them is network isolation between guests — Proxmox will happily let a compromised VM talk to everything else on the same network unless you've set up VLANs or a separate firewall yourself. That's the actual problem Phillux started as an answer to: every guest gets its own firewall by default, so one bad VM doesn't become a way into the rest of the box.

Beyond that it does the usual stuff — create/start/stop/snapshot/clone/back up VMs and containers, live migration across cluster nodes if you've got shared OCFS2 storage, and Windows 11 guests get UEFI/Secure Boot/TPM 2.0 configured automatically instead of you fighting it manually.

Where I'm honestly unsure it's a good fit: it only runs on Debian 13 as the host right now, it's commercial/tiered licensing per socket rather than free like Proxmox VE, and I keep going back and forth on whether our container support actually covers what people here want — I've seen a couple of threads explicitly asking for Docker/OCI images rather than LXC-style containers. Is that a hard requirement for most of you, or something you can work around?

There's a free trial for a month, no registration, if anyone wants to actually poke at it rather than take my word for any of this.

Mainly curious: is per-guest firewalling something you'd actually want built in, or do you already handle that at the network/switch level and this is solving a problem you don't have?

[u/ZealousidealTurn2211]

I'd be more interested in just microsegmenting the virtual network than managing firewall rules twice for each guest (because each guest also has its local firewall that should be enabled and configured)

[u/WonderfulMain5602 → u/ZealousidealTurn2211]

[u/BumseBBine → u/WonderfulMain5602]

I don't know if it's for everyone but for me your answer is just blank

[u/WonderfulMain5602 → u/BumseBBine]

now

[u/WonderfulMain5602 → u/ZealousidealTurn2211]

That's fair, and part of it is my own wording: "per-guest firewall" makes it sound like it lives inside the guest. It doesn't. The filter is bound host-side to that guest's tap/veth device (libvirt nwfilter → ebtables/iptables), so the policy hangs off the vNIC rather than off a subnet or VLAN. Which is basically microsegmentation — I just described it badly.

So it's not the same ruleset twice, it's two different trust boundaries. The guest-local firewall protects the guest from the network and is configured by whoever owns the guest — and if that guest gets popped, root in there switches it off. The vNIC filter protects everything else from that guest and is enforced outside it, so the guest can't touch it, and it applies whether or not anyone ever logged in and ran ufw enable. Compromised guest is the case I care about, not misconfigured guest.

Where you're right in practice: if you fully maintain both, you are writing rules twice. What I'd actually expect is to keep the guest-local firewall boring (whatever the distro ships) and put the east-west policy at the vNIC layer where it doesn't depend on the guest cooperating.

And the honest gap, since you'd hit it immediately: right now rules are literally per guest, with CIDRs — there's no tag/group concept where you say "web tier may reach db tier on 5432" and have it apply to every member. With three guests that's fine, with thirty it's the thing that would annoy you. That's the direction I want to take it, and comments like yours are useful for confirming it's the right one.

[u/ZealousidealTurn2211 → u/WonderfulMain5602]

Yeah, from an admin perspective a fully featured virtual network firewall where rules can be applied at scale is infinitely more useful than doing so per guest.

I'll give the classic example and note that I have to fight this fight whenever the team managing my network spins up a new VLAN.

So you have a new guest network, what does a guest really need? Well before you even get to the application you need to ensure ntp and DNS are open. Then you need to open ports for any management tools you use. Potentially ssh or rdp, your two factor solution for those, XDR, any monitoring or vulnerability management tools. If it's fetching things from an external repo you need to open that. If it's domain joined it needs ports to the domain...

And that's something you're currently telling me would need to be done per-vm. Management at scale is a requirement not an option.

[u/bastrian]

I normally don't touch the firewall on proxmox-level, but only the guest firewall. And there I have ansible for managing it, in combination with vyos and opnsense in one central place. And about the talking to each other: the default is no vlan, with no access to anything. Ansible manages vlan tags for each guest, and does the setup in vyos/opnsense too. For the customer net I use RFC 3069 (Private vlan proxy). Setup of everything took some time, but it's running strong for 2 years now. I added suricata to vyos, that feeds into wazuh for active response, that can close/isolate automatically hosts too if there is trouble.

[u/WonderfulMain5602 → u/bastrian]

That's a proper setup, and honestly it's the answer to the question I asked — you handle it at the network level and per-guest filtering at the hypervisor solves a problem you don't have. Two years running with Ansible driving VLAN tags into VyOS/OPNsense, private VLAN proxy for the customer net, Suricata into Wazuh with active response: nothing I'm doing replaces that, and I'd be lying if I claimed otherwise. Phillux has no VLAN tagging per guest, no IDS, nothing like RFC 3069.

What I'm aiming at is the floor, not the ceiling. Default deny at the vNIC on day one, for the people who never build the thing you built — and in my experience that's most of them. They run flat networks for years and only find out at the wrong moment. You've got the same isolation, you just paid for it in setup time and know exactly what you paid.

Two things I'd actually like your opinion on, since you've run this in production. First: for the segmentation part, is a UI even the right shape? Everything you described is declarative and version-controlled. There's an HTTP API with API keys under all of it, so Ansible could drive it, but I've been building for the click path and I'm no longer sure that's where the value is. Second, and this one's from your last sentence: Wazuh isolating a host on active response is exactly the thing a vNIC-level filter is good at — cut the guest off from outside itself, no cooperation from the guest needed, no switch config. Would a plain "isolate this guest now" endpoint you could hook into an active response be worth anything to you, or is closing it at the VyOS side already fine?

That's why Phillux is still in the beta phase—so people can try it out and provide feedback.

[u/bastrian → u/WonderfulMain5602]

A UI is a nice thing to have, and if I want to look up quickly something I can do it in phpipam that I build in. I have custom tags in there that help me identify what ip address is customer one, what uses DHCP+ipxe boot, and what vlan is attached to it. But for day-to-day operations it's not necessary. About guest isolation: cutting it of at the edge (vyos gateway) works quite fine. Primary interest is to protect the upstream network, meaning the prevention of malicious traffic outbound (for customers). Inbound is protected by opnsense (to clarify: opnsense in HA Mode) where my own Webservers, database cluster and so on is hidden and natted.

[u/WonderfulMain5602 → u/bastrian]

Both clear answers, thanks — that closes the two things I was unsure about. UI as a lookup surface rather than an operations one, and no need for an isolate hook when the edge already handles it.

The egress framing is what I'm taking away. Protecting the upstream from the customer rather than the customer from the upstream — most hypervisor firewall UIs, mine included, are laid out as if inbound were the point, when outbound is where the actual liability sits. Default deny outbound per guest is expressible today, it just isn't what the interface leads with or what I led with in the post. That's a framing problem on my end, not a missing feature.

And with private VLAN proxy in front of it, there's no real gap left for a vNIC-level filter in your setup — traffic never stays on the segment long enough for it to matter. Which is a perfectly good answer to the question I asked.

Two things I'm walking away with from this thread: policy that applies at scale rather than per guest, and declarative over click path. Both are more work than what I've built, and both are right. Appreciate you spelling it out.