pfSense & OPNsense on Proxmox: Building Your Router as a VM

pfSense or OPNsense: Pick Either

This guide covers both projects together because the install steps are nearly identical: same FreeBSD-derived base, same VM shell, same interface-assignment flow at first boot. OPNsense forked from pfSense in 2014 over disagreements about the direction of the project and has since built its own plugin ecosystem and a faster release cadence. pfSense Community Edition is backed by Netgate, who also sell pre-built appliances and a paid Plus tier, and has the larger base of existing forum answers if something goes sideways.

For a home network, it's a coin flip. Pick whichever project's web UI and terminology you find more comfortable, since you'll be living in it for firewall rules and DHCP reservations from here on.

The Networking Decision That Actually Matters

Every other guide on this site has a passthrough section about disks or USB devices. This one is about the network path itself, since a router VM's whole job is standing between your Proxmox host and the internet.

• Linux bridges (recommended to start): create one bridge per physical role, typically vmbr0 for Proxmox's own management access, vmbr1 bridged to the physical port running to your modem for WAN, and vmbr2 bridged to the port(s) running to your LAN switch. Assign the VM's virtual NICs to the matching bridges. Bridges let you add more VMs or containers onto any of those networks later without touching cabling, at a modest performance cost, typically single-digit gigabits on a 10G link rather than full line rate.
• PCI passthrough (better performance, less flexible): pass a physical NIC directly through to the VM (requires IOMMU enabled in the Proxmox host's BIOS and boot config, plus machine type q35). The router VM gets near-native throughput, but it can no longer be live-migrated to another node, and the NIC is unavailable to the host or any other guest while it's passed through.

On a single physical NIC, both interfaces can still run through one VLAN-aware bridge: enable VLAN awareness on the bridge, tag the VM's WAN and LAN virtual interfaces with different VLAN IDs, and set the switch port feeding Proxmox to trunk mode so it carries both tags. Every other device on the network plugs into a switch port assigned to the LAN VLAN.

One practical safety note: do the interface assignment and any WAN/LAN swap from the Proxmox console (the VM's own screen, opened from the Proxmox web UI), not over a network connection that depends on the change you're about to make. It's a two-minute job if something's misassigned and you're watching the console. It's a much longer one if you've locked yourself out of the box you need to fix it from.

The VirtIO Disconnect Issue

Worth knowing about ahead of time rather than discovering it during a video call: older FreeBSD releases have shipped VirtIO network driver bugs that show up as the connection randomly dropping every few minutes, with "no buffer space available" errors in the system log. It's been reported often enough on both the Proxmox and Netgate forums to be a known issue rather than a misconfiguration on your end.

Two fixes, either works: run a current pfSense or OPNsense release, since this has been resolved in recent FreeBSD versions, or change the affected interface's model from VirtIO to Intel E1000 in the VM's Hardware tab, which trades some throughput ceiling for a driver with a longer track record. If you're already on a current release and still seeing it, also check System → Advanced → Networking for the hardware checksum offload setting. Disabling it has fixed traffic that looks fine in a packet capture but silently never arrives, a classic symptom of the VM and hypervisor disagreeing about who's responsible for the checksum.