Running pfSense or OPNsense as a Proxmox VM: Best Practices and WAN Passthrough

For a long time, a firewall VM on Proxmox sounded like one of those ideas people either praised as elegant or dismissed as irresponsible.

I understand both instincts.

If it works well, it can feel beautifully structured. One capable host, one clean hypervisor, one virtual firewall, one place to snapshot, back up, and reason about the edge. But if the design is sloppy, the consequences are not theoretical. You can absolutely make the host’s own connectivity depend on the VM that is supposed to be protecting everything else.

What finally made the whole subject click for me was realizing that the question is not “Is virtualizing a firewall good or bad?” The better question is:

"Where do WAN and LAN really live, who owns the physical NICs, and what happens when the firewall VM is down?"

Once those answers are honest, the design becomes much easier to trust.

For the technical baseline below, I use Netgate's official documentation and separate documented platform behavior from my own placement and operating recommendations.

A firewall VM is different because it can sit underneath the rest of your network

This is the first thing I think people should say out loud.

When you virtualize an application server, the host remains the floor underneath it.
When you virtualize the firewall, the relationship can become more circular.

The host may depend on the firewall VM for:

• upstream internet access;
• routing between VLANs;
• DNS resolution paths;
• remote access back into the environment;
• sometimes even the network path that lets you manage the hypervisor itself.

That does not make the design wrong.
It does mean the firewall VM deserves more architectural honesty than an ordinary guest.

The official documentation is more comfortable with virtualization than people sometimes expect

Netgate’s pfSense virtualization documentation is very clear: pfSense software can run in a variety of Type-1 and Type-2 environments, and the best practice for production is to use a Type-1 hypervisor. Their Proxmox VE recipe goes further and gives a direct working pattern for Proxmox specifically.

The OPNsense documentation is similarly comfortable with virtualization. Its virtual-installation guide explicitly covers local server virtualization, gives minimum RAM and disk guidance, and includes KVM-specific notes such as support for both i440FX and Q35.

That matters because it resets the conversation.

Neither project is treating virtualization as a weird unsupported trick.
The real question is not whether the VM can exist.
The real question is whether the network boundaries around it are sensible.

For most homelabs, “WAN passthrough” should usually mean a dedicated WAN bridge first

This is the biggest conceptual cleanup I would make.

When people say “WAN passthrough,” they often mean one of two very different things:

• the WAN connection is handed to the firewall VM through a dedicated Linux bridge attached to a physical NIC;
• the physical WAN NIC itself is passed directly into the VM as a PCI device.

Those are not the same design.

Netgate’s Proxmox VE recipe clearly recommends the first model as the standard path: use at least two host interfaces, create two Linux bridges in Proxmox VE, and dedicate one for WAN and one for LAN. Their example keeps Proxmox management on a separate interface, then binds one physical NIC to a WAN bridge and another to a LAN bridge, with the pfSense VM using VirtIO NICs on those bridges.

I think this is the cleanest default for most homelabs.

Why?

Because it gives the firewall VM:

• a real dedicated external path;
• a real dedicated internal path;
• no unnecessary sharing of the WAN bridge with unrelated guests;
• much more flexibility than PCI passthrough;
• easier VM lifecycle handling.

This is also very consistent with how Proxmox bridge design works best in general. Bridges should represent clean responsibilities, not prestige.

VirtIO on dedicated bridges is usually the right balance of performance and sanity

Netgate’s Proxmox guide explicitly uses VirtIO (paravirtualized) network adapters for the pfSense VM, and OPNsense’s virtualization docs include KVM guidance rather than warning people away from virtual NICs entirely.

That matches my bias too.

A bridged dedicated NIC path with VirtIO gives you most of the goodness people actually want:

• good virtualization performance;
• easy interface replacement inside the VM definition;
• snapshots and backup behavior that still feel like VM behavior;
• no VFIO or IOMMU dependency just to get a firewall online;
• less host specificity than full PCI passthrough.

For most homelab firewalls, that is the sweet spot.

Offloading settings matter much more here than they do on many ordinary VMs

This is one of the most important practical details in the official docs.

Netgate says that when using VirtIO interfaces in Proxmox VE, network interface hardware checksum offloading must be disabled, and their documentation is very direct that this should not be skipped. OPNsense says essentially the same thing in its own way: disable all hardware off-loading settings in Interfaces -> Settings for virtual installations.

That alignment between both projects is important.

It tells me this is not a random tuning superstition.
It is a real virtualization best practice for these firewall platforms.

So if I were building either pfSense or OPNsense on Proxmox, I would treat this as a first-day item, not a later optimization:

• install the VM;
• assign WAN and LAN cleanly;
• get console or GUI access;
• disable hardware offloading inside the firewall OS;
• reboot and confirm traffic behavior afterward.

Keep Proxmox management outside the firewall VM’s blast radius if you can

This is the habit that makes the whole setup feel calmer.

Netgate’s Proxmox example assumes the host has at least two interfaces for WAN and LAN, and its sample layout uses a third interface for Proxmox VE management. I think that is excellent design when the hardware allows it.

A dedicated management path means:

• the host does not lose all reachability when the firewall VM is being rebuilt;
• WAN experiments do not automatically strand the hypervisor;
• recovery work stays possible even if the virtual router is temporarily broken.

This is one reason I would avoid letting the Proxmox management address sit casually behind the same fragile first-pass network story that the new firewall VM is still trying to become.

If the hardware is limited, there are still workable designs.
But if I have enough NICs, I want management recoverability to be obvious.

PCI passthrough of the WAN NIC is valid, but it is not the default best practice

This is where I think a lot of people over-romanticize the harder option.

Direct PCI passthrough of a WAN NIC to pfSense or OPNsense can make sense.
It can be justified when:

• the guest truly needs direct hardware ownership;
• a specific NIC driver or behavior matters inside the firewall OS;
• you want to remove even the small abstraction of a bridged virtual NIC path;
• the node’s role is intentionally becoming “the firewall host.”

But this choice should be understood as an architectural trade.

As the official Proxmox live-migration requirements state, passed-through PCI devices block live migration. That means the moment you pass through the WAN NIC directly:

• the VM becomes less portable;
• maintenance flexibility drops;
• hardware replacement assumptions tighten;
• the firewall guest becomes much more node-specific.

That may still be worth it.
It just should not be mistaken for a free upgrade.

This is the same mindset I described in Proxmox GPU passthrough. Direct assignment is not only about performance. It is about ownership and the loss of abstraction.

For most homelabs, bridge the WAN NIC cleanly before you pass it through

If the question is “What should I try first?”, my answer is simple:

1. Give the firewall VM a dedicated WAN bridge backed by a physical WAN NIC.
2. Give it a dedicated LAN bridge or VLAN-aware internal path.
3. Use VirtIO NICs.
4. Disable offloading inside the guest.
5. Keep host management recoverable outside that path if possible.

Only after that would I ask whether PCI passthrough is solving a problem I actually still have.

That sequence matters because many people reach for passthrough when what they really needed was cleaner bridge responsibility.

Firmware, console access, and recovery posture still matter

Netgate’s Proxmox recipe also notes some practical VM details that I think are worth keeping in mind:

• pfSense can boot UEFI in Proxmox VE, but it requires extra steps;
• when using UEFI, they recommend q35, OVMF, and an EFI disk;
• on some versions, adding a serial port makes EFI booting more reliable.

OPNsense’s KVM documentation notes support for both i440FX and Q35, and its broader docs also make it easy to install a QEMU guest agent plugin if wanted.

I would not overcomplicate this part early, but I would absolutely care about one thing:

make sure there is a console path you trust when the network path is broken.

That can mean:

• Proxmox console access;
• a serial-capable VM path when appropriate;
• an out-of-band management route to the host itself.

A firewall VM becomes much less scary once you know exactly how you will reach it when the network rules are wrong.

My preferred mental model is “virtual appliance with explicit boundaries”

This is the model that made the whole idea feel calm to me.

I do not think of pfSense or OPNsense on Proxmox as “just another VM.”
I think of it as a virtual appliance whose value depends on how explicit its boundaries are:

• one path for WAN;
• one path for LAN or internal trunks;
• one clear offloading posture;
• one clear management-recovery story;
• one honest answer to whether bridging is enough or hardware passthrough is actually required.

That is why the design can be excellent without needing to be maximalist.

Conclusion

Running pfSense or OPNsense as a Proxmox VM can be an excellent homelab design when the network paths are explicit and recoverable. For most builds, the best starting point is not direct PCI passthrough of the WAN NIC, but a dedicated WAN bridge backed by its own physical NIC, paired with a similarly deliberate LAN path and VirtIO interfaces. Both pfSense and OPNsense documentation also agree on an easy-to-miss detail that matters a lot: disable hardware offloading in the guest. Once those basics are right, the firewall VM stops feeling like a trick and starts feeling like infrastructure.