How to Install OPNsense on Proxmox VE: Step-by-Step Guide

If you’re moving off a dedicated appliance and onto a hypervisor, here’s how to install OPNsense on Proxmox VE without fighting the two most common failure points: a firewall VM with no working network path, and an installer that boots but never gets past interface assignment. This covers bridge setup, VM sizing against OPNsense’s published hardware tiers, the installer wizard, and the NIC model choice that actually matters once you’re past 1 Gbps.

What You Need Before You Start

Proxmox VE 8.x host with at least one spare physical NIC for WAN, or a managed switch trunk if you’re doing VLANs upstream.
The current OPNsense DVD (VGA) image from the official OPNsense downloads page — the serial-console image is for headless bare metal, not what you want for a Proxmox VM console.
At minimum, 2 vCPUs, 4 GB RAM, and a 40 GB virtual disk. OPNsense’s own documentation lists 1 GHz dual-core / 3 GB RAM as the bare minimum tier and 1 GHz dual-core / 4 GB RAM / 40 GB SSD as the “reasonable” tier where every standard feature actually works, including the IDS/IPS alert database and caching proxy. For a home router doing Suricata inspection on a gigabit WAN, budget toward the 8 GB / 120 GB “recommended” tier instead.

Step 1: Build the Bridges Before You Touch the VM

OPNsense needs a minimum of two interfaces, WAN and LAN, and each needs its own Proxmox bridge — bridging both to the same vmbr0 will not give you isolation, it’ll just give you a routing loop. On the Proxmox host, go to Datacenter > > System > Network and create a second Linux Bridge, per the Proxmox VE Network Configuration wiki:

vmbr0 — bridged to your WAN-facing physical NIC (e.g., the onboard port wired to your ISP ONT or modem). No IP assigned on the Proxmox side; OPNsense owns this address.
vmbr1 — no physical port attached, purely internal, becomes your LAN segment (e.g., 192.168.1.0/24).

If you’re running downstream VLANs (IoT on VLAN 20, guest on VLAN 30), add a third bridge or trunk them through vmbr1 with 802.1Q tags handled inside OPNsense rather than at the Proxmox bridge layer — it’s one less place to misconfigure a PVID. The tagging, per-VLAN DHCP scopes, and inter-VLAN block rules are covered in the OPNsense VLAN configuration guide.

Step 2: Create the VM

Upload the ISO to local storage, then Create VM with these settings:

OS: Linux (works fine for a FreeBSD-based guest; this only affects Proxmox’s default tweaks, not the actual OS)
BIOS: OVMF (UEFI) matches the OPNsense DVD image’s UEFI support; SeaBIOS also works if you prefer legacy boot
Disk: VirtIO SCSI single controller, 40–120 GB depending on your tier, discard enabled if backed by SSD/NVMe
CPU: type host (or x86-64-v2-AES if you migrate between mismatched hosts and want AES-NI for IPsec/OpenVPN without breaking live migration), 2–4 cores
Memory: 4096–8192 MB, ballooning off — a firewall VM getting memory reclaimed mid-flow-table-lookup is not a fun debugging session
Network: add two NICs, one on vmbr0 (WAN) and one on vmbr1 (LAN)

Step 3: VirtIO vs e1000 — Pick Deliberately

This is the one setting people get wrong twice. VirtIO NICs are paravirtualized and will comfortably clear 1 Gbps where an e1000 emulated NIC caps out around line-rate gigabit due to emulation overhead. A detailed Proxmox forum writeup on running OPNsense with VirtIO recommends setting the Multiqueue field to match your vCPU count (e.g., 4 queues for 4 cores) to actually get the throughput benefit — VirtIO with multiqueue left at 0 barely beats e1000.

The tradeoff: OPNsense’s traffic shaper doesn’t fully cooperate with VirtIO’s queue behavior, so if ALTQ-based shaping or bufferbloat control is central to your setup, some operators deliberately stay on e1000 for predictability at the cost of a hard 1 Gbps ceiling. For a straight routing/firewall/IPS box on a sub-gigabit WAN, e1000 is fine and one less variable. For 2.5G+ WAN or heavy inter-VLAN routing, use VirtIO with multiqueue set.

Either way, leave the Firewall checkbox unticked on both VM network devices in Proxmox’s per-NIC settings. Proxmox’s own datacenter firewall stacked in front of OPNsense’s stateful firewall is redundant at best and a source of dropped packets you’ll spend an hour debugging at worst.

Step 4: Run the Installer

Boot the VM, and OPNsense’s installer walks a fixed sequence per the official install guide: keymap, filesystem choice, partitioning, target disk, swap, and root password. Choose ZFS over UFS if your virtual disk is 40 GB or larger — the docs call it the more reliable option, and on a Proxmox-backed disk you get the benefit without the write-amplification concerns that matter more on SD/CF media. Default installer credentials are installer / opnsense; after install, first boot login is root / opnsense — change that password before this box ever touches a public WAN.

Step 5: Assign Interfaces and Reach the GUI

On first boot you’ll hit the console menu to assign WAN and LAN to the correct virtual NICs — get this backwards and you’ll be configuring your ISP’s DHCP server as your internal LAN, which is a bad time. Once assigned, LAN defaults to 192.168.1.1/24 with a DHCP range active; browse to https://192.168.1.1 (port 443, self-signed cert on first run) from a client plugged into the LAN-side bridge to finish setup through the web GUI. From here the wizard, the root password change, and the management-plane lockdown are identical to a bare-metal box, so follow the OPNsense initial setup guide from the first-boot section onward.

Common Pitfalls

Both bridges on the same subnet: if vmbr0 and vmbr1 end up carrying the same IP range, you’ll get asymmetric routing and broken NAT. Keep WAN and LAN on distinct bridges with distinct subnets, full stop.
PCIe passthrough as an alternative: if you want a physical NIC to bypass the Proxmox bridge entirely (lower latency, no vSwitch in the path), passthrough requires IOMMU enabled in BIOS and vfio-pci bound to that NIC before VM start — more setup, but it isolates WAN from Proxmox’s own networking stack completely.
Skipping the multiqueue setting: leaving VirtIO multiqueue at the default of 0 while expecting VirtIO’s full throughput advantage is the most common “why is my 2.5G WAN capped at 900 Mbps” ticket in Proxmox’s own forums.