Virtual install on Proxmox — virtio, VLAN trunking, sizing the VM

Most OPNsense labs and a growing share of production deployments are virtualised. Proxmox VE is a common platform: it is KVM-based, supports ZFS, has a clean web UI, and runs the same Proxmox course this RunBook Academy teaches. This lesson covers how to install OPNsense as a Proxmox VM, the NIC choice that matters, the VLAN trunking pattern that lets one vNIC carry many VLANs, and the VM sizing that maps the production workload onto virtual hardware.

The Proxmox OPNsense layout

The standard layout is:

Proxmox host (physical)
├─ vmbr0 (Linux bridge, untagged) ← WAN physical NIC attached
├─ vmbr1 (Linux bridge, untagged) ← LAN physical NIC attached
├─ vmbr2 (Linux bridge, tagged)   ← trunk physical NIC attached
└─ OPNsense VM
    ├─ net0: virtio, bridge=vmbr0, WAN
    ├─ net1: virtio, bridge=vmbr1, LAN
    └─ net2: virtio, bridge=vmbr2, VLAN trunk (optional)

The operator’s first decision is how many physical NICs the host has and how they map to bridges. Two common patterns:

• Two NICs. vmbr0 = WAN (one physical NIC, untagged on the upstream switch), vmbr1 = LAN (one physical NIC, possibly a trunk if the operator plans internal VLANs).
• Three or more NICs. One per logical network (WAN, LAN, DMZ, management), each a separate bridge. Cleaner separation, more hardware.

$ qm config 100 | grep -E '^net[0-9]+'

net0: virtio=00:50:56:00:00:01,bridge=vmbr0,firewall=0
net1: virtio=00:50:56:00:00:02,bridge=vmbr1,firewall=0
net2: virtio=00:50:56:00:00:03,bridge=vmbr2,firewall=0

NIC choice: virtio vs e1000

OPNsense on KVM supports two NIC models that matter. The choice is a tradeoff.

The default recommendation: virtio. OPNsense’s kernel includes the virtio_net driver; virtio gives near-line-rate throughput with the lowest CPU overhead. e1000 is the fallback for guests that lack the virtio driver — OPNsense does not need it.

Two warnings the operator should know:

1. virtio and NIC offload. Some virtio offload features (TSO, UFO) interact poorly with PF state matching. OPNsense disables problematic offloads by default; the operator can verify with ifconfig <iface> | grep options.
2. Live migration. virtio NICs with explicit MAC addresses migrate cleanly between Proxmox hosts. The operator sets the MAC explicitly (virtio=00:50:56:...) rather than relying on the random default.

VLAN trunking on a single vNIC

The Proxmox host has a limited number of physical NICs. An operator who needs to carry multiple VLANs to the firewall can use a single trunk NIC and create VLAN interfaces on the firewall.

Pattern:

1. On the Proxmox host, the physical NIC is the only member of a Linux bridge (e.g. vmbr2), and the bridge has no IP.
2. The OPNsense VM has one net device attached to that bridge.
3. Inside OPNsense, the operator creates VLAN interfaces on the parent interface for each VLAN ID the firewall needs (Interfaces → VLANs).
4. The upstream switch port is configured as a trunk with the relevant VLANs allowed.

The result: one physical NIC on the Proxmox host carries the WAN traffic (untagged or with the WAN’s own VLAN tag) plus every internal VLAN the firewall needs. The OPNsense VM sees the parent interface plus a VLAN interface per tag.

$ qm set 100 --net1 virtio,bridge=vmbr2,tag=10

updating VM 100: -net1 virtio,bridge=vmbr2,tag=10
Logical volume "vm-100-disk-0" successfully created.

Two ways to do VLANs:

• Proxmox-side tag (qm set --netX tag=N). Proxmox strips the VLAN tag before handing the frame to the VM. The VM sees untagged traffic on the vNIC. Useful when the operator wants the VM to handle only one VLAN.
• OPNsense-side VLAN interfaces. No Proxmox tag. The VM sees tagged frames on the vNIC. OPNsense creates VLAN interfaces for each tag. The operator uses this when the VM needs to handle multiple VLANs on one vNIC.

The course uses the second pattern (OPNsense-side VLAN interfaces) for the production VLAN setup; the lesson on VLAN design covers it in detail.

VM sizing

The VM CPU, RAM, and disk allocations map the production workload onto virtual hardware. The course’s sizing lesson establishes the floors; the VM is sized within those.

vCPU

The vCPU count maps to the binding constraint from the sizing exercise. A firewall that needs 4 cores for IPSec + Suricata gets 4 vCPUs; one that does no crypto and no IDS can run with 2 vCPUs. The operator does not over-commit vCPUs on a busy firewall — over-commitment hurts latency and tail latency.

For best performance on a busy link, the operator enables multiqueue on the virtio NIC and pins the queues to the vCPUs. Proxmox sets this with qm set --netX queues=N; the guest sees N RX/TX queue pairs that map to N vCPUs.

RAM

Static allocation (no ballooning). The RAM is reserved for the firewall VM at boot; Proxmox does not reclaim it. Ballooning introduces latency and is not suitable for a busy firewall.

Disk

virtio-scsi for the disk controller (best performance), with the disk image on a ZFS pool or a Ceph pool depending on the storage stack. The disk size is the OPNsense base plus headroom for logs, RRD graphs, and Suricata’s eve.json.

$ qm set 100 --scsihw virtio-scsi-pci --scsi0 local-zfs:vm-100-disk-0,size=32G,ssd=1,iothread=1

update VM 100: -scsihw virtio-scsi-pci -scsi0 local-zfs:vm-100-disk-0,size=32G,ssd=1,iothread=1

Install sequence

The install sequence on Proxmox:

1. Upload the ISO. Download the OPNsense ISO from https://opnsense.org/download/ and upload to local storage (Datacenter → Storage → local → Upload).
2. Create the VM. Create VM in the Proxmox UI, set the OS to “Other” and the ISO to the uploaded OPNsense ISO. Set CPU to host, machine type to q35.
3. Configure disks and NICs. Add a virtio-scsi disk sized for the deployment. Add the virtio NICs attached to the right bridges. firewall=0 on every vNIC.
4. Boot and install. Boot the VM; the OPNsense installer appears; follow the install prompts. Use the default ZFS install for UEFI.
5. Remove the ISO. Detach the ISO from the VM’s CD-ROM drive before the first reboot; otherwise the VM boots into the installer again.
6. Run the wizard. The first boot presents the wizard; the lesson on the initial wizard walks through it.

$ qm set 100 --ide2 local:iso/OPNsense-25.7-vga-amd64.iso,media=cdrom

update VM 100: -ide2 local:iso/OPNsense-25.7-vga-amd64.iso,media=cdrom

Anti-patterns

Three anti-patterns the course has seen repeatedly:

1. Using e1000 because “it’s safer”. e1000 is emulated software; throughput caps around 1 Gbps with high CPU overhead. virtio gives near-line-rate at a fraction of the CPU. The compatibility concern that drives the e1000 choice is unfounded — OPNsense’s kernel has virtio_net.ko built in.
2. Leaving the Proxmox firewall on. Double-filtering hurts throughput. The Proxmox firewall is for VMs that have no firewall of their own; OPNsense has PF. Set firewall=0.
3. Ballooning RAM. Ballooning reclaims RAM from the guest under memory pressure. On a busy firewall, ballooning introduces latency spikes during reclaim. Use static RAM allocation.

Summary

• The standard Proxmox layout: bridges per physical NIC, OPNsense VM attached, firewall=0 on every vNIC.
• NIC choice: virtio (default, near line rate, low CPU) vs e1000 (fallback for unusual cases only).
• VLAN trunking: leave Proxmox untagged, create VLAN interfaces in OPNsense for each VLAN the VM needs.
• VM sizing: host CPU, q35 machine, virtio-scsi disk, static RAM, no ballooning, multiqueue on busy NICs.