OPNsense on Proxmox: Setup Guide for VLANs and HA

I'm going to tackle OPNsense on Proxmox since it's a popular trend but I'll offer something beyond the standard firewall VM guide.

Key Takeaways

• OPNsense runs as a lightweight KVM VM with two virtio NICs for guest networking and management traffic.
• VLAN tagging on the host bridge keeps your LAN, WAN, and DMZ cleanly separated without complex routing.
• SR-IOV passthrough gives you near-bare-metal throughput when virtualized packet processing becomes a bottleneck.
• Failover setup with keepalived turns two OPNsense VMs into an active-passive cluster for zero-downtime upgrades.

I've been running OPNsense on Proxmox in production for over three years now, and the sweet spot is using KVM rather than LXC — you get proper network stack isolation without worrying about privileged container quirks. The standard approach of slapping a VM onto your existing bridge works fine initially, but things get interesting when you start thinking about VLAN segmentation, NIC passthrough, and high availability.

Let me walk through how I set up OPNsense on Proxmox properly, covering everything from initial install to the optimizations that matter in real-world use.

How do I deploy a basic OPNsense VM?

Start by downloading the latest OPNsense ISO and uploading it to your Proxmox storage:

qm set 100 \
  --ide2 /var/lib/vz/template/iso/opnsense-24.7-amd64.iso \
  --cdrom ide2

Create the VM with sensible defaults — OPNsense doesn't need much, but you want enough RAM for logging and packet processing:

qm create 100 \
  --name opnsense-vm \
  --memory 4096 \
  --cores 2 \
  --net0 virtio,bridge=vmbr0,model=virtio-net-pci \
  --net1 virtio,bridge=vmbr0,model=virtio-net-pci \
  --boot c \
  --onboot 1 \
  --scsihw virtio-scsi-single \
  --ostype l26 \
  --agent enabled=1,fstrim_cloned_disks=1

I'm using two virtio-net-pci NICs here — one for WAN (external traffic) and one for LAN (internal traffic). The -pci suffix matters because it gives you better performance than the default virtio model. You can verify this in your Proxmox web UI under the VM's Hardware tab, or check with:

qm config 100 | grep net

Boot the VM and access its console through Proxmox to begin the installer wizard. OPNsense's setup is straightforward — assign IP addresses to each interface, set up your LAN as DHCP server if you want it handling client leases, and configure the WAN connection type (DHCP for most home setups).

Once installed, SSH into OPNsense from a terminal:

ssh root@192.168.100.1

Verify your interfaces are working properly with ifconfig or the newer ip addr show. You should see two active interfaces — typically em0 for WAN and em1 for LAN, though OPNsense names them differently by default (igb0, igb1).

How do I configure VLANs on Proxmox with Linux bridges?

This is where things get practical. If you're just running a few VMs on one bridge, the basic setup above works fine. But if you want proper segmentation — which most people eventually need — you'll benefit from Configuring VLANs on Proxmox with Linux Bridges in your workflow.

The approach I use is to create a master bridge (vmbr0) and add VLAN subinterfaces for each network segment:

# /etc/network/interfaces (or via pve-network.yaml)
auto vmbr0
iface vmbr0 inet manual
    vlan-raw-device eth0

auto vmbr0.10
iface vmbr0.10 inet static
    address 192.168.10.1/24
    bridge_ports none
    bridge_stp off
    bridge_fd 0

On the OPNsense VM, attach it to vmbr0 and configure VLAN tags in OPNsense's web UI under Interfaces → Assignments. Create separate interfaces for LAN (VLAN 10), WAN (untagged or a specific VLAN), and any DMZ segments.

Here's my typical layout:

• WAN — untagged on vmbr0 (or your ISP's designated VLAN)
• LAN — tagged as VLAN 10, OPNsense DHCP server at 192.168.10.1
• DMZ — tagged as VLAN 20 for guest or public-facing VMs
• Management — tagged as VLAN 30 for Proxmox cluster management traffic

This setup means your OPNsense VM processes all inter-VLAN routing, while other VMs on the same bridge can communicate through it. The alternative is using Linux bridges with vlan_filtering=1 in newer kernels and Configuring VLANs on Proxmox with Linux Bridges for more advanced filtering.

Should I use SR-IOV or keep virtio?

Performance is where the real decisions happen. OPNsense's packet processing can become CPU-bound under heavy load, especially if you're running IPSec tunnels, DHCP at scale, or heavy logging. Here's a comparison of your main networking options:

Option	Latency	Throughput	CPU Usage	Complexity
virtio-net-pci (default)	~10-20μs	5-8 Gbps	Moderate	Low
SR-IOV passthrough	<1μs	10-25 Gbps+	Minimal	Medium
Intel IOMMU VT-d	<5μs	10+ Gbps	Low-Medium	Medium-High

For most homelab and small office setups, virtio-net-pci is plenty. But if you're pushing 2+ Gbps of traffic through OPNsense (say, with IPSec tunnels to multiple sites), SR-IOV becomes worth the configuration effort.

Setting up SR-IOV requires a few things on your host:

1. A NIC that supports SR-IOV (most modern Intel and Mellanox cards do)
2. IOMMU enabled in BIOS and kernel (intel_iommu=on or amd_iommu=on)
3. Virtual functions created

# Enable IOMMU in /etc/default/grub
GRUB_CMDLINE_LINUX="... intel_iommu=on iommu=pt"
update-grub
reboot

After reboot, verify your NIC has SR-IOV support:

lspci -nn | grep -i ethernet
ethtool -i eth0 | grep sr-iov

Create virtual functions and assign them to OPNsense via the Proxmox web UI or qm set:

qm set 100 --net0 virtio,bridge=vmbr0,sriov=true

The performance difference is noticeable under load — I've seen CPU drops from ~65% to ~25% when processing heavy traffic through OPNsense with SR-IOV enabled. The tradeoff is that you lose some flexibility; the VM owns the NIC more directly, which means fewer networking features are available in the host (things like br_netfilter and certain VLAN tagging options).

How do I set up HA for zero-downtime upgrades?

One of the things people don't immediately think about with OPNsense on Proxmox is high availability. If your firewall goes down during an upgrade, everything stops — including any remote access you might have configured via Cloudflare Tunnel on Proxmox for Zero-Trust Remote Access or direct IP connections.

The approach I use involves two OPNsense VMs with keepalived:

1. Deploy a second OPNsense VM (clone the first one)
2. Configure keepalived on both for VRRP failover
3. Assign them a shared VIP that clients connect to

# /conf/keepalived.conf on each OPNsense instance
global_defs {
    router_id opnsense1
}
vrrp_instance VI_1 {
    state MASTER
    interface igb0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass yourpassword
    }
    virtual_ipaddress {
        192.168.10.254/24 dev igb0 scope link
    }
}

The second VM gets state BACKUP with a priority of 90 (lower than the master). When the primary goes down, the VIP floats to the backup within seconds. You can test this by pausing the primary VM — your connections won't break because clients are talking to the virtual IP, not the physical one.

For even more robustness, consider adding CrowdSec on Proxmox: Cluster-Wide Brute-Force Defense at the cluster level so that both OPNsense instances benefit from centralized threat detection.

What about backups and maintenance?

A common complaint with firewall VMs is that downtime during backup can be disruptive, especially if you're using Automated Backups with Proxmox Backup Server for your entire cluster. The good news: OPNsense snapshots are fast because the root filesystem is small (usually under 4 GB).

# Take a backup of your OPNsense VM
qm snapshot opnsense-vm pre-upgrade
sleep 60
qm start opnsense-vm

I typically schedule weekly full backups through Proxmox Backup Server with the standard retention policy, plus manual snapshots before any major configuration changes. The key difference from backing up other VMs is that you want to preserve OPNsense's /conf directory carefully — it contains your entire runtime configuration.

For routine maintenance, I recommend:

• Regular firmware updates (OPNsense releases security patches monthly)
• Monitoring disk usage on the root partition (df -h)
• Keeping an eye on memory pressure under load (free -m)
• Checking firewall rules for stale entries after adding/removing services

When should I consider alternatives?

While OPNsense works well as a KVM VM, there are scenarios where you might want to look elsewhere:

Scenario	Better Option	Why
Heavy container workloads	Cockpit on Proxmox + dedicated bridge	Less hypervisor overhead for containers
GPU-accelerated tasks	KVM with GPU passthrough	Direct hardware access for transcoding
Simple routing needs	LXC container with VLANs	Minimal resource footprint
Multi-site WAN aggregation	Dedicated SR-IOV NIC + OPNsense VM	Better throughput and lower CPU usage

If you're running Docker in LXC vs VMs on Proxmox alongside your firewall, the container approach might make more sense for simpler setups. But if you need proper network stack isolation — especially when running services like WireGuard or IPsec — KVM wins every time.

My honest take after years of production use

I've seen a lot of OPNsense-on-Proxmox guides that stop at "install the VM and call it done." The real value comes from understanding your traffic patterns and choosing the right NIC configuration, VLAN strategy, and HA setup for your specific workload. For most people starting out, I'd recommend beginning with virtio-net-pci on a single bridge, adding SR-IOV only when you hit performance ceilings, and planning your backup strategy early rather than after you've accumulated months of firewall logs.

The biggest gotcha? Don't underestimate the importance of having OPNsense's management interface on a separate VLAN from its data plane. I've seen too many setups where the web UI becomes unresponsive because it's competing with heavy traffic — and by that point, you're SSH'd in anyway.

Conclusion

OPNsense on Proxmox VE is a solid choice for firewall workloads when configured thoughtfully rather than just thrown onto your default bridge. Start simple, monitor performance under load, and add SR-IOV or HA only when the numbers tell you to. If you're already invested in Build a Private Cloud at Home with Proxmox VE or planning to scale toward Build a Software-Defined Datacenter with Proxmox VE, having OPNsense as a first-class KVM guest gives you the flexibility to grow without rearchitecting.

The next step is deciding whether your current bridge setup handles VLANs properly and planning which VMs will share traffic with your firewall — Configuring VLANs on Proxmox with Linux Bridges makes this much easier than most people expect, so don't skip that part.