Running OPNsense as a Firewall VM on Proxmox

Answer first: when a virtual firewall makes sense

Running OPNsense as a Proxmox guest is a well-trodden, production-viable pattern — with a clear profile of when it's the right call:

Do it when the firewall's job is guarding the virtual estate: an OPNsense VM as the gateway for your other guests gives you inter-VLAN routing, a proper DMZ, VPN termination, and IDS/IPS for everything behind it — plus the virtualisation dividends: snapshot before every upgrade, config restore in minutes, and no second chassis to rent. On a single dedicated server hosting many VMs, it's the natural design.

Think twice when the firewall must be independent of the hypervisor — if OPNsense is the perimeter for infrastructure beyond this host, every Proxmox reboot takes your network down with it — or when you need every last gigabit with hardware offloads, where bare metal (or NIC passthrough) still has the edge.

One design rule up front, learned the hard way by everyone who skipped it: never make the Proxmox host's own management interface depend on the OPNsense VM. The host's SSH/web UI must remain reachable via its own path — otherwise a firewall VM that won't boot locks you out of the very hypervisor you'd fix it from. (KVM-over-IP is the backstop, but don't design to need it.)

Network design on a dedicated server

This builds directly on the bridge model from our Proxmox networking guide — OPNsense simply becomes a guest with a leg in two (or more) bridges:

• WAN: a virtual NIC on vmbr0 (the public bridge), configured with an additional public IP assigned to your server — respecting the provider's MAC policy, exactly as for any bridged guest. On our network, additional IPs come with the server and this Just Works.
• LAN: a virtual NIC on an internal bridge (bridge-ports none — a switch with no uplink, e.g. vmbr1). Every guest that should live behind the firewall attaches here and uses OPNsense's LAN address as its gateway.
• More segments: either more internal bridges, or — cleaner at scale — one VLAN-aware internal bridge with OPNsense taking a trunk and routing between tagged segments. That's a DMZ, a management net, and a lab, all firewalled at one point.

The Proxmox host itself keeps its management IP on vmbr0 (or better, a dedicated management interface), not behind the OPNsense VM — per the rule above. Guests get defence in depth: our network-edge firewall upstream, OPNsense at the segment boundary, and on-host rules inside each guest where warranted.

The VM configuration that works

The community (and the well-maintained virtualisation HOWTO on the official OPNsense forum) has converged on a recipe; deviating from it is where the mystery bugs live:

Sizing honesty: OPNsense's official hardware guidance tops out its tiers at "750+ Mbit/s" for the 8 GB "recommended" spec and publishes no exact virtualised-gigabit figure — the 2–4 vCPU / 4–8 GB recipe is community-established guidance, comfortable for routing a gigabit with a normal ruleset. State-table RAM is rarely the issue (roughly 1 KB per connection state); Suricata IDS/IPS is — inline inspection is CPU-hungry and is what pushes a small firewall VM to 4+ cores.

The offloading footnote that saves you a weekend

Historic pain: VirtIO NICs plus hardware checksum offload on FreeBSD guests caused dropped packets and broken connectivity. Modern OPNsense ships with the right answer already — hardware checksum/TSO/LRO offloading disabled by default (Interfaces → Settings). So the actionable advice in 2026 is: verify those boxes stay ticked ("disable") and don't "optimise" by re-enabling them on VirtIO interfaces. If an OPNsense VM passes traffic weirdly — some sites load, others hang — this setting is suspect number one.

Installing, condensed

1. Upload the OPNsense installer ISO (current series: 26.1; the project ships two majors a year, January and July) to Proxmox and boot the VM from it.
2. Log in as installer, install to disk choosing ZFS, reboot.
3. At the console, assign interfaces: VirtIO NICs appear as vtnet0, vtnet1… — match them to WAN/LAN by the MAC addresses shown in the Proxmox hardware panel (set them memorably distinct when creating the VM; future-you says thanks).
4. Set WAN to your assigned public IP/gateway and LAN to your internal range (e.g. 10.0.0.1/24), then open the web UI from a guest on the LAN bridge — or via an SSH tunnel through the host — and run the setup wizard.
5. First stops after the wizard: update to current, install os-qemu-guest-agent, take your first snapshot.

Day-2 operation is where the VM form factor shines: snapshot → upgrade → verify → delete snapshot turns OPNsense's twice-yearly majors from a maintenance risk into a non-event, and PBS backs up the whole firewall nightly like any other guest.

What about pfSense?

The same recipe applies nearly verbatim to pfSense — also FreeBSD, also VirtIO-happy. Between the two: pfSense CE remains alive (2.8.x current, 2.9 in development) alongside the commercial pfSense Plus, while OPNsense's predictable two-majors-a-year cadence, fully open model, and modern UI have made it the default recommendation in the self-hosting world these past years. If you already know one, run it; if starting fresh, this guide picked OPNsense on purpose.

Frequently asked questions

Should I pass a physical NIC through to OPNsense instead of using VirtIO?

Default to VirtIO — it's the current community recommendation, keeps the VM fully virtual (snapshots, migration, no IOMMU wrangling), and routes a gigabit comfortably. PCI passthrough still earns its complexity in two cases: chasing maximum throughput with hardware offloads on multi-gigabit links, or wanting the WAN cable physically isolated from the hypervisor's network stack. If you do pass through, the VM loses live-migration and easy-snapshot ergonomics — you're trading away the reasons to virtualise.

Does OPNsense protect the Proxmox host too?

Not in this design — and it shouldn't. The host's management plane stays on its own path (deliberately not behind the firewall VM), protected instead by the upstream edge firewall, its own rules, and never exposing the web UI (port 8006) publicly. Routing the host's own traffic through a guest it hosts creates a circular dependency with exactly one failure mode: total lockout. Guests behind OPNsense; host beside it, independently hardened.

How much performance do I lose versus bare metal?

For plain routing/NAT at gigabit scale on modern cores: little enough that VirtIO's convenience wins — the official spec tiers put even modest hardware in the "750+ Mbit/s" class, and a properly configured VM sits in that band. The honest costs appear at the extremes: multi-gigabit throughput (paravirtualised networking's per-packet overhead adds up; consider passthrough) and IDS/IPS (Suricata's inspection is the real CPU bill wherever it runs). Measure your own path before optimising — and see the editor's benchmark above.

Can I run this highly-available?

CARP (OPNsense's VRRP-style failover) works virtualised, but think through what it buys on one host: two firewall VMs on the same hypervisor share every hardware failure mode, so intra-host CARP mostly covers upgrade windows — which snapshots already handle. Real firewall HA means OPNsense VMs on two hosts with the LAN segments spanning them (VLANs over private networking, or VXLAN via Proxmox SDN) — worth it when the guests behind it justify cluster-grade design generally.

Deploying on Serverside

Everything this pattern needs comes with a Proxmox dedicated server here: additional public IPs for the WAN leg, private networking that carries your VLANs between hosts for the multi-server designs, always-on DDoS mitigation upstream of the whole arrangement, and KVM-over-IP as the never-locked-out backstop. Proxmox comes pre-installed; the OPNsense ISO is an upload away.

Round it out with the Proxmox networking deep-dive this design builds on, backup strategies for the firewall VM itself, and — for the WireGuard-native alternative at the routing layer — our VyOS site-to-site guide.