Configure Software Firewalls inside VMs: UFW / iptables vs Proxmox Firewall

For a long time, I treated firewalling in a homelab like a question with one correct location.

Either the firewall belongs on the edge.
Or it belongs on the hypervisor.
Or it belongs inside the guest.

What took me too long to understand is that those are not competing answers.
They are different sentences in the same paragraph.

That matters a lot in Proxmox, because the moment you start running several VMs, each guest becomes its own little machine with its own services, habits, and ability to surprise you. A careful Proxmox host can still contain a guest that suddenly listens on something it should not. And a carefully configured guest can still benefit from a stronger outer boundary on the hypervisor side.

So when people ask whether they should use UFW or iptables inside a VM, or just rely on Proxmox Firewall, I do not think the best answer is “pick one.” I think the better answer is: decide which layer should express which intent.

Proxmox Firewall is a boundary around the guest, not a replacement for the guest

The official Proxmox Firewall documentation describes multiple logical zones where rules can be applied independently. That alone tells you something important: Proxmox is thinking about traffic in relation to the platform boundary, not as a replacement for every firewalling decision inside an operating system.

That is the mental shift I wish I had earlier.

Proxmox Firewall is excellent when you want to say things like:

• this VM should only receive traffic on a small set of ports;
• this management guest should only be reachable from a certain subnet;
• this exposed service belongs in a tighter perimeter than the rest of the lab;
• this interface should be protected before traffic even reaches the guest.

That is powerful, especially when paired with cleaner segmentation ideas like the ones behind a virtual isolated DMZ in Proxmox or careful VLAN trunking to VMs and containers.

But once traffic is allowed through the hypervisor boundary, the guest is still a real operating system. It still has processes listening on ports. It still has package updates. It still has the potential to drift.

That is where host-based firewalls keep their value.

UFW is usually the cleanest answer when the VM is an Ubuntu-style service box

Ubuntu’s own firewall documentation describes UFW as the default firewall configuration tool and a friendly way to manage a host-based firewall. That is exactly why I keep returning to it for simple Linux guests.

If the VM is doing one or two straightforward jobs, UFW often gives me the right balance:

• default deny for inbound traffic;
• explicit allow rules for SSH, web, or app ports;
• readable status output later when I have forgotten what I did;
• less friction when I revisit the guest months later.

That last point matters more than people admit.

A homelab does not stay in the clean emotional state it had on day one. Six months later, you are tired, you are troubleshooting something else, and you are trying to remember why this VM was reachable from half the network. In that moment, ufw status numbered is emotionally kinder than rediscovering a pile of hand-built rules you no longer recognize.

So if a VM is basically:

• a reverse proxy;
• a small internal app server;
• a management utility;
• a personal service with predictable ports;

then UFW is often enough inside the guest.

Not because it is magical.
Because it is legible.

iptables is still valuable when you need precision, not friendliness

The netfilter project describes iptables as the userspace command-line program for configuring Linux packet filtering rulesets. That wording feels exactly right: rulesets, not just toggles.

And that is why iptables still has a place.

If I need unusual matching logic, tighter scripting control, or behavior that goes beyond the comfortable shape of UFW, raw iptables can still be the more honest tool. It lets you be very explicit about what the guest should accept, reject, log, or forward.

But this is also where I think many homelabs become harder than they need to be.

Using iptables inside a VM just because it feels more advanced is rarely the best reason. The right reason is that the guest genuinely needs the extra precision. If it does not, then the complexity becomes another future burden.

In other words:

• use UFW when the guest needs clear host-level policy and the rule set is normal;
• use iptables when the guest needs lower-level control and you actually plan to maintain it.

I do not think “more powerful” automatically means “more mature.”
Sometimes it just means “more expensive to revisit.”

The two layers catch different kinds of mistakes

This is the part that finally made the model click for me.

Proxmox Firewall protects the guest from the outside in.
The guest firewall protects the operating system from the inside out.

Those are related, but they are not identical.

Imagine a VM that is only supposed to expose HTTPS and SSH to a management subnet.

At the Proxmox layer, I can declare that narrow outer boundary.
Inside the guest, I can still say:

• only this service port should be reachable;
• loopback and established traffic should behave normally;
• an accidentally installed service should not become reachable just because it started listening;
• local service policy should remain visible with the VM itself if it ever moves or gets rebuilt.

That last point is one of the most practical reasons to keep a firewall inside the VM. A guest-level policy travels with the operating system. If that VM is restored elsewhere, cloned, migrated conceptually, or simply audited by someone looking only at the guest, the local intent is still present.

Proxmox Firewall, by contrast, is superb at expressing platform intent:

• which subnets should ever touch this guest;
• which interfaces deserve protection;
• which VMs belong in stricter outer zones;
• where broad mistakes should be stopped before they even reach the guest kernel.

I do not want to lose either statement.

The cleanest pattern is usually outer perimeter plus inner service awareness

When I look at homelab setups that age well, they usually separate responsibilities in a boring way.

Boring is good here.

I would usually let Proxmox Firewall express outer reachability:

• which source networks can talk to the VM;
• which exposed ports are even allowed to arrive;
• which sensitive guests deserve tighter default rules;
• which lab segments should stay separated unless explicitly opened.

Then I would let the guest firewall express host-level truth:

• which services on the OS are intentional;
• what the default inbound posture should be;
• whether temporary software changes accidentally widened exposure;
• what the VM itself believes should be reachable.

That layered model feels much healthier to me than placing all trust in either side alone.

If I only use Proxmox Firewall, I risk treating the guest like a sealed object when it is actually a living OS.
If I only use the guest firewall, I give up a very useful enforcement point that exists before packets even fully belong to the VM.

Neither is wrong.
Both are incomplete on their own.

Where this matters most in real homelab design

I think this matters most in three kinds of guests.

First, infrastructure VMs.
If I am running routing, DNS, reverse proxies, or internal management services, I want both a narrow hypervisor perimeter and a local OS-level statement of allowed traffic. That is especially true when the VM participates in more complex networking ideas, like running pfSense or OPNsense as a Proxmox VM.

Second, internet-adjacent services.
Anything even vaguely exposed, proxied, or reachable from remote contexts should not depend on a single firewall layer if I can avoid it.

Third, long-lived utility guests.
These are the dangerous ones because they feel harmless. A file helper, a sync box, a dashboard VM, a small admin tool. Over time they gather packages, experiments, and forgotten changes. A simple UFW policy inside the VM often becomes the line that keeps drift from turning into quiet exposure.

My practical rule of thumb

If the VM is disposable, tiny, and only lives briefly for testing, Proxmox Firewall alone may be enough.

If the VM is persistent, reachable, or important, I would usually do this:

1. use Proxmox Firewall to define the outer network perimeter;
2. use UFW inside the VM if the guest is a normal Ubuntu-style service host;
3. use iptables only when the guest truly needs lower-level rule control;
4. document which layer owns which decision;
5. avoid duplicate complexity unless the duplication provides a real safety net.

That last line matters.

Layering does not mean mirroring every rule in two places with no reason. It means each layer should carry a clear responsibility. Otherwise you do not get defense in depth. You get administrative fog.

Verification note: Commands, terminology, and support details in this guide were cross-checked against the official Proxmox firewall documentation.

For broader context, continue with Installing Proxmox VE for the First Time: A Practical Guide and Understanding Proxmox Storage Types: Local-ZFS, LVM-Thin, and Directory.

Conclusion

Proxmox Firewall and software firewalls inside VMs should not be treated like rivals, because they are describing different boundaries. Proxmox’s own documentation frames firewalling around logical zones and protected interfaces at the platform level, while Ubuntu’s UFW guidance and the netfilter iptables model remain host-based controls inside the guest operating system. Once I understood that distinction, the whole debate became less ideological and much more practical.

In a healthy homelab, I think the best pattern is usually simple: let Proxmox define outer reachability, let the guest define its own local service truth, and only reach for raw iptables when the VM genuinely needs precision beyond a cleaner UFW policy. That approach is not flashy, but it ages well, and in homelab infrastructure, aging well is often the real mark of good design.

FAQ

Is Proxmox Firewall alone enough for most VMs?

Sometimes, especially for short-lived or tightly scoped guests. But for persistent service VMs, I think it is usually better to keep a host-based firewall inside the guest as well, so the operating system still expresses its own allowed-service intent.

Should I use UFW or iptables inside a VM today?

If the guest is a normal Ubuntu-style server with straightforward ports, I would start with UFW because it is easier to read and maintain. I would only reach for raw iptables when the VM needs more precise or unusual packet-filtering behavior that UFW would make awkward.