Virtualizing the firewall moves the network edge into the hypervisor

A bare-metal firewall can be rebooted independently of servers. An OPNsense VM shares the fate of its Proxmox node unless the architecture includes a second firewall or another recovery path. That consolidation can be worthwhile, but it changes maintenance procedures.

Plan upgrades, storage failures and host reboots as network events. If the office cannot tolerate the firewall disappearing during hypervisor maintenance, the design needs redundancy rather than a faster NIC.

Virtualizing the firewall changes the failure domain. A routine Proxmox reboot, bridge edit or host NIC problem can now affect internet access as well as the other guests. A workable design therefore needs a recovery path that does not depend on the OPNsense VM being healthy: local console, IPMI/iKVM where available, or a clearly documented physical access procedure. That operational requirement matters as much as the virtual NIC benchmark.

Proxmox Linux bridges are software switches

Proxmox documentation describes vmbr interfaces as Linux bridges that connect guests to physical networks. OPNsense can attach VirtIO network interfaces to these bridges just as a physical firewall attaches ports to external switches.

This model keeps the physical NIC under host control, which can make monitoring, VLAN-aware bridging and VM reconfiguration straightforward. It also lets several guests share a physical interface when the design permits.

For routed OPNsense deployments, a Linux bridge can act as the virtual switch connecting a VirtIO interface to a physical NIC or VLAN-aware uplink. Direct PCIe passthrough instead transfers ownership of a device to the guest and needs functioning IOMMU isolation. Neither choice removes the need to separate WAN and trusted management paths logically and physically enough that a configuration mistake does not lock administrators out of the Proxmox host.

VirtIO preserves virtualization flexibility

A VirtIO NIC is a paravirtualized interface optimized for virtual machines. It avoids emulating a specific physical network card and can integrate cleanly with Proxmox bridges.

For many OPNsense deployments, VirtIO is the sensible first path because it keeps the VM less tied to one PCI device. Benchmark the actual workload before assuming passthrough is required.

PCI passthrough gives OPNsense direct device ownership

With passthrough, the host assigns a PCIe NIC to the OPNsense VM through IOMMU/VFIO. This can simplify the guest's view of physical ports and can be useful when a specific driver or netmap behavior matters.

The cost is coupling. The VM depends on that hardware resource and its IOMMU group, live migration becomes more complicated, and the host cannot use the same NIC for its own bridge.

IOMMU groups should be checked before hardware purchase

Proxmox passthrough requires compatible CPU/platform firmware and kernel configuration. Just because a motherboard has a free PCIe slot does not guarantee the device will be isolated in a useful IOMMU group.

Inspect the actual platform or choose hardware with known separation. Avoid buying a multi-port card solely for passthrough before verifying how the board groups its PCIe devices.

Separate WAN and management failure domains

The Proxmox management address should not be reachable only through the OPNsense VM if that VM is the object of maintenance. A separate management NIC, management VLAN reachable through an alternate path, or local console strategy can prevent lockout.

Document the host gateway carefully. An edge-firewall VM creates circular dependencies easily if the host needs that same firewall to reach repositories or administrative workstations.

VLAN trunks can terminate at the host or the guest

Proxmox Linux bridges support VLAN-aware configurations, including guest tags and trunk mode. OPNsense can also receive a trunk and create its own VLAN interfaces. Both designs are valid when ownership is clear.

A common source of confusion is tagging the same network twice or filtering it at both layers unintentionally. Draw where tags enter, where they are stripped and which device owns each network.

10GbE raises the cost of an unclear virtual path

At higher link speeds, host bridge configuration, CPU scheduling, offload behavior and PCIe topology become more visible. A setup that was stable at 1GbE should still be retested after a 10GbE upgrade.

Use repeatable bidirectional tests and monitor host CPU, guest CPU and interface counters. The goal is to identify the limiting layer rather than blame virtualization as one undifferentiated overhead.

IDS/IPS deserves its own validation plan

OPNsense transparent-bridge documentation notes potential VLAN and virtualization complications with netmap and advises bare metal for that specific bridged VLAN scenario. Routed virtualized OPNsense designs are different, but the warning reinforces the need to test driver-sensitive inspection paths.

If IPS is a production requirement, test it with the final NIC model, VLAN mode and Proxmox network path. Do not certify the design using routing-only benchmarks.

Backup and restore are part of network availability

Keep OPNsense configuration exports and Proxmox VM configuration backups available outside the node. A host storage problem should not erase the information needed to rebuild the site firewall.

Record interface MAC addresses and bridge assignments. After restore, OPNsense interface names or virtual NIC ordering can differ, and a clear mapping prevents accidental WAN/LAN reversal.

A dedicated firewall remains a valid alternative

Consolidation is not automatically the best architecture. A small separate firewall can make Proxmox maintenance independent of internet access and can simplify failure isolation.

Compare the value of one more appliance with the operational complexity of virtualizing the edge. The live catalogue includes dedicated multi-gig appliances so the decision can be priced rather than treated as ideology.

A final OPNsense-on-Proxmox checklist

Verify management independence, WAN/LAN mapping, NIC drivers, bridge or passthrough ownership, IOMMU groups, VLAN handling, backup access, startup order and what happens when the host reboots.

Then test from cold boot: can the node start, OPNsense obtain WAN connectivity, LAN clients reach the firewall, management remain available and VLANs route correctly without manual intervention?