VirtIO keeps networking inside the virtualization model

With VirtIO, OPNsense sees a high-performance virtual NIC rather than the underlying physical adapter. Proxmox connects that interface to a Linux bridge, and the host owns the physical port and its driver.

This abstraction is valuable because the VM configuration can remain stable while the host network changes. Moving from one physical adapter to another may require only bridge changes rather than rebuilding OPNsense interface assignments.

VirtIO and passthrough solve different operational problems. VirtIO keeps the guest attached to Proxmox's software network layer, which is convenient for bridges, VLAN-aware designs and host-level reconfiguration. Passthrough gives OPNsense direct control of the PCIe device, which can be attractive for driver-sensitive or netmap-sensitive workloads, but the device is no longer freely available to the host and guest mobility becomes more constrained.

Passthrough removes the host bridge from that NIC path

PCI passthrough assigns a physical network adapter to OPNsense through VFIO/IOMMU. The guest then loads the driver for the physical controller and sees its real ports.

This can be useful when a specific FreeBSD driver or direct hardware behavior is required. It also means the Proxmox host cannot simultaneously use the same device as a bridge port.

Benchmarking should mirror the real firewall path. A large sequential transfer between two hosts can hide packet-per-second limits, rule-processing cost or IDS/IPS behavior that appears with many small flows. Test the actual WAN/LAN or inter-VLAN path, enable the production rule set, and repeat with the intended inspection features. Keep a rollback method before changing the only interface that provides Proxmox management access.

Performance is not a universal one-number comparison

The difference between VirtIO and passthrough depends on CPU, packet size, offloads, bridge configuration, interrupts, NUMA placement, firewall rules and OPNsense services. A forum benchmark on different hardware is not a specification for your server.

Test the exact workload. Measure routed traffic, bidirectional traffic, CPU utilization and the security features that matter, then decide whether the operational cost of passthrough buys a useful improvement.

IOMMU groups can decide the passthrough answer before software does

A NIC can only be passed safely when the host can isolate the relevant PCI function or device group. Motherboard slot wiring, ACS behavior and multifunction devices influence the grouping.

Inspect the intended host before purchase when possible. A second smaller NIC can be easier to isolate than a complex multi-function card on a consumer platform.

Migration and failover favor virtual interfaces

A VirtIO network device is a VM configuration object that can exist on another compatible Proxmox node as long as the corresponding bridge is available. A passed-through NIC is a physical resource that must also exist and be mapped on the destination.

If firewall HA depends on moving workloads between nodes, this difference is significant. Device resource mappings can help, but the hardware still has to be present and equivalent.

VLAN design is often cleaner when ownership is explicit

With VirtIO, Proxmox can provide a VLAN-aware bridge or trunk to OPNsense. With passthrough, the guest can own the physical trunk directly. Both are workable.

Problems appear when some VLAN decisions live on the host, others in the guest and nobody can explain the boundary. Pick one model, document it and test it from switch to firewall.

IDS/IPS can justify testing passthrough without making it mandatory

OPNsense uses netmap for inline intrusion prevention and documents driver-specific behavior. Direct ownership may simplify some hardware paths, but passthrough does not automatically guarantee a target inspection rate.

Run the IPS ruleset you plan to deploy and observe packet drops, CPU, interface counters and stability. A passthrough decision should be backed by a measured need.

Host observability is better with a bridge

When the Proxmox host owns the physical NIC, administrators can inspect bridge state and interface counters from the hypervisor. This can simplify debugging when the VM is unavailable.

With passthrough, more of the link state moves into OPNsense. That can be desirable for isolation, but it changes where the troubleshooting tools live.

Passthrough can make firewall recovery more hardware-specific

A restored OPNsense VM expecting a passed-through X710 cannot simply start on a node without an equivalent mapped device. VirtIO reduces that dependency by presenting a stable virtual interface.

If passthrough is chosen, keep spare compatible hardware or a documented fallback bridge configuration so recovery does not depend on sourcing one old adapter during an outage.

Security boundaries should be understood, not assumed

Direct device assignment can reduce host involvement for a specific NIC, but the firewall VM still depends on the hypervisor for CPU, memory and lifecycle. VirtIO adds a host software-switch layer but may be operationally easier to audit and update.

Choose based on your threat model and maintenance capability. Neither architecture makes the hypervisor irrelevant.

A two-stage deployment reduces risk

Build the OPNsense VM with VirtIO first, verify routing, VLANs and policy, then benchmark. If a driver-sensitive feature or throughput target fails, test passthrough using the same rules and traffic.

Changing one layer at a time creates useful evidence. Starting with passthrough, tuning, offloads and VLAN changes simultaneously makes it difficult to know what solved or caused a problem.

A final VirtIO versus passthrough checklist

Use VirtIO when mobility, simple bridges, shared host networking and easy hardware replacement dominate. Test passthrough when direct controller ownership, a specific driver path or measured bridge limitation matters.

Before choosing passthrough, verify IOMMU, device isolation, destination-node hardware, recovery procedure and an independent host-management path.