Should You Run OPNsense on Proxmox in Production?

Running OPNsense as a virtual machine on Proxmox can be a reliable production design. It can reduce hardware costs, simplify backups and make firewall recovery faster than rebuilding a failed physical appliance.

The design also creates an important dependency. If OPNsense provides internet access, routing and remote management for the same Proxmox host that runs it, a hypervisor or networking failure can disconnect the entire environment.

You should run OPNsense on Proxmox in production only when the server, networking and recovery design account for this failure domain. The virtual machine itself is rarely the weak point. Poor bridge configuration, missing console access and a lack of redundancy create the greater risks.

Is OPNsense Supported as a Virtual Machine?

OPNsense officially documents virtual installations and provides installation images that can run from virtual disks. Its virtual deployment guidance recommends at least 3 GB of memory, an 8 GB virtual disk and disabling hardware offloading settings for compatibility. citeturn565327search2turn565327search25

Proxmox uses KVM to provide full virtual machines with their own guest operating system and kernel. It also uses a bridged networking model in which virtual network interfaces connect to software bridges that operate similarly to Ethernet switches. citeturn110973search0turn110973search12

This makes Proxmox technically suitable for hosting OPNsense. The more important question is whether the surrounding design is suitable for production.

What Are the Benefits of Virtualizing OPNsense?

The first advantage is efficient hardware use. A dedicated firewall appliance may use only a fraction of its processor and memory. Proxmox can allocate the remaining resources to other infrastructure services.

Virtualization also makes replacement easier. If a physical firewall fails, administrators may need compatible replacement hardware before service can be restored. A virtual OPNsense system can be restored on another Proxmox node if compatible storage and networking are available.

Proxmox can back up complete virtual machines, including their virtual disks and configuration. Its integration with Proxmox Backup Server adds incremental backups, deduplication and structured restore workflows. citeturn565327search38turn110973search1

OPNsense also provides its own configuration backup system. Administrators can export encrypted configuration files and automatically send backups to remote services. A configuration file can be imported during installation to rebuild the firewall on new hardware or in a new virtual machine. citeturn110973search6turn110973search9turn110973search19

These two backup layers serve different purposes. A Proxmox backup restores the entire virtual firewall. An OPNsense configuration backup can rebuild the firewall independently of the original virtual machine.

What Is the Biggest Production Risk?

The primary risk is placing the firewall and the infrastructure required to access that firewall on the same host.

Consider a single Proxmox server running OPNsense. The OPNsense virtual machine provides internet access, DHCP, DNS and VPN connectivity. The Proxmox management interface is reachable only through a network routed by OPNsense.

If the Proxmox host stops, the firewall stops. Remote users lose their VPN, and administrators may also lose the route needed to reach Proxmox. A minor virtualization failure can therefore become a complete network outage.

The design needs a recovery path that does not depend on the OPNsense virtual machine. This may include a dedicated management interface, an isolated management network, local console access or a server management controller.

You should be able to open the Proxmox console, inspect the OPNsense virtual machine and correct bridge settings even when normal routing is unavailable.

How Should You Design the Proxmox Networking?

A basic deployment normally uses separate Proxmox bridges for external and internal traffic.

The external bridge connects the OPNsense WAN interface to the internet connection. The internal bridge connects the OPNsense LAN interface to virtual machines, physical switches or internal VLANs.

The Proxmox management interface should not be attached carelessly to an internet facing bridge. Proxmox provides its own firewall controls, but the management interface should still remain on a trusted network and should not be directly exposed to the public internet. Proxmox firewall rules can be applied at cluster, host and virtual machine levels. citeturn110973search11

Proxmox network configuration supports bridges, bonds, VLANs and routed designs. Production deployments should document which physical interface connects to each bridge and how VLAN tags move between Proxmox, OPNsense and the physical switches. citeturn110973search15

A networking mistake can affect both the firewall and hypervisor. Make changes from a console when possible, especially when modifying the bridge that carries management traffic.

Should You Use Virtual Interfaces or PCI Passthrough?

Most deployments can use virtual network interfaces connected to Proxmox bridges.

Virtual interfaces make the OPNsense machine easier to back up, migrate and restore. They also allow several virtual workloads to share a physical network adapter through the Proxmox bridge.

PCI passthrough gives the OPNsense virtual machine direct control over a physical network card. Proxmox supports passing an entire PCI device, including a network adapter, to a KVM virtual machine. citeturn110973search4turn110973search45

Passthrough can create clear separation between the firewall and the Proxmox networking layer. It may also be useful for specialized interfaces or high traffic environments.

The tradeoff is reduced portability. A virtual machine using a passed through card depends on that card being present in the selected Proxmox node. Live migration and automatic recovery become more difficult.

For many small and medium deployments, Proxmox bridges provide the better balance. Use passthrough when there is a measured performance, compatibility or security reason.

How Much Performance Can a Virtual OPNsense Firewall Deliver?

The required resources depend on connection speed, firewall rules, VPN encryption, intrusion prevention and traffic reporting.

Simple routing and filtering require relatively modest resources. Suricata intrusion prevention, traffic inspection and high speed VPN connections can create much greater processor demand.

OPNsense recommends disabling checksum offloading, TCP segmentation offloading and large receive offloading in many firewall and virtualized scenarios. Its documentation notes that some offloading features are incompatible with intrusion prevention or can create routing problems. citeturn565327search0turn565327search19

Do not size the virtual machine only according to average bandwidth. Measure processor use during backups, VPN peaks, intrusion detection updates and heavy concurrent traffic.

Reserve enough Proxmox capacity so other virtual machines cannot starve the firewall. A firewall that competes with application workloads for processor time can produce latency even when the physical network adapters are not saturated.

How Should Startup and Shutdown Be Handled?

OPNsense should start before most workloads that depend on routing, DHCP, DNS or internet access.

Proxmox supports automatic guest startup and configurable startup order and delays. Administrators can start the firewall first, allow time for its services to initialize and then start application virtual machines. Proxmox uses the reverse order during shutdown, allowing dependent workloads to stop before the firewall. citeturn565327search40

Do not assume that a running virtual machine means the network is ready. OPNsense may need time to initialize interfaces, establish VPN tunnels and confirm gateway availability.

Test a complete Proxmox host reboot. Confirm that OPNsense starts correctly and that dependent systems recover without manual intervention.

Do You Need Two OPNsense Virtual Machines?

A single OPNsense virtual machine cannot provide uninterrupted service during a host failure.

OPNsense supports high availability through CARP. Two firewalls can share virtual addresses, synchronize firewall states and allow the secondary system to take over when the primary becomes unavailable. OPNsense recommends a dedicated interface for state synchronization. citeturn565327search1turn565327search3

The two firewall virtual machines should run on separate Proxmox nodes if they are intended to protect against host failure. Running both on one physical server protects only against a failure inside one firewall guest.

The Proxmox cluster must also have reliable quorum. Proxmox recommends at least three nodes for dependable high availability quorum. citeturn110973search16

CARP depends on network behaviour such as multicast, MAC address movement and gratuitous ARP. OPNsense warns that virtualized switching environments can complicate CARP if the network layer restricts those functions. The complete failover path must be tested rather than assumed. citeturn565327search3

How Should Updates and Backups Be Managed?

Export the OPNsense configuration before every major change. Keep copies outside the Proxmox cluster so they remain available during a storage or cluster failure.

Also create a verified Proxmox backup before major OPNsense upgrades. Snapshots can provide a quick rollback option, although changes made after the snapshot will be lost when rolling back. OPNsense recommends retaining configuration backups alongside snapshots for this reason. citeturn110973search33

Updates should be tested on a secondary firewall or laboratory copy first. Avoid upgrading OPNsense and Proxmox during the same maintenance window. Separate changes make failures easier to diagnose.

Should You Run It in Production?

Yes, OPNsense can run successfully on Proxmox in production.

The design is appropriate when you have reliable server hardware, separated network bridges, protected management access, automatic startup ordering and backups stored outside the firewall virtual machine.

For critical networks, use two OPNsense systems on separate Proxmox nodes and test CARP failover under realistic conditions.

A physical firewall remains simpler when the environment has one Proxmox server, no independent management path and no administrator available locally during an outage.

Virtualizing OPNsense provides flexibility and fast recovery. It also ties network availability to the health of the virtualization platform. Production readiness depends on whether that dependency has been deliberately designed and tested.