How to Set Up OPNsense as a Virtual Firewall/Router in Proxmox VE

Introduction

Most homelabbers eventually hit the same wall: they've got a Proxmox VE box running half a dozen VMs and containers, and their "router" is still whatever locked-down ISP modem-router combo showed up in the mail. No VLANs, no real firewall rules, no IDS, no way to segment a smart-home network from the machine holding your backups. The fix a lot of people reach for is a dedicated firewall appliance running OPNsense — but buying a second box just to run a firewall feels wasteful when you already have a hypervisor sitting there with CPU and RAM to spare.

The good news is you don't need a second box. Proxmox VE can run OPNsense as a virtual machine and hand it real network interfaces to work with, effectively turning your existing server into both your hypervisor and your router. It's a common enough pattern that OPNsense ships VirtIO drivers in its kernel specifically so this works cleanly, and Proxmox's bridge model maps onto a firewall VM's WAN/LAN split without much friction.

It's also a setup that punishes sloppy planning. Get the network topology wrong, and you can end up in a state where the only device with internet access is the firewall VM itself, or where a Proxmox reboot leaves you with no way to reach the web UI at all because the firewall that used to route to it never came back up cleanly. This guide walks through the whole process end to end — planning the network layout, building the VM correctly, installing and configuring OPNsense, and the specific gotchas that trip people up on this exact combination of software.

What You Will Learn

• How to plan a WAN/LAN network layout for a virtualized firewall using Proxmox bridges
• How to build an OPNsense VM in Proxmox VE with the correct hardware settings
• How to install OPNsense and assign its network interfaces correctly on first boot
• How to run the OPNsense setup wizard and get LAN clients online through the VM
• The checksum-offload bug that breaks connectivity on this exact pairing, and how to fix it
• How to keep a way into your Proxmox host if the firewall VM ever fails to boot

What Is This Feature?

OPNsense is a free, open-source firewall and routing platform built on FreeBSD, descended from the same pfSense/m0n0wall lineage that a lot of homelab and small-business networks run on. On its own hardware it replaces your router entirely: it handles WAN connectivity, NAT, DHCP, DNS, VLAN routing, VPN endpoints, and stateful firewall rules, all through a web interface.

Running it as a VM inside Proxmox doesn't change any of that — OPNsense has no idea it's virtualized, and doesn't need to. What changes is how it gets its network interfaces. Instead of physical NIC ports, it gets VirtIO network devices that Proxmox bridges to your real network hardware (or to other VMs, for fully internal networks). One virtual NIC becomes the WAN interface, wired to whatever bridge has your internet uplink; a second becomes LAN, wired to a bridge the rest of your VMs and physical devices connect to. From OPNsense's point of view, it's just two network cards, same as a physical box.

Why Would You Use It?

The obvious appeal is consolidation — one box instead of two, no separate firewall appliance to buy, power, and maintain. But there's a real functional upside too. A virtualized firewall gets snapshots. Before you change a firewall rule set you're not confident about, you take a Proxmox snapshot, make the change, and if it breaks your network you roll back in seconds instead of trying to remember what the old ruleset looked like. Try that with a physical pfSense box.

It also opens up flexibility that dedicated hardware doesn't have. Need a second, isolated test network for VLAN experiments? Add another virtual bridge and a firewall rule — no new cabling, no new switch port. Want to try OPNsense's IDS/IPS features without committing hardware to it? Spin it up, test it, tear it down.

The tradeoff is that your firewall now depends on your hypervisor staying up. If Proxmox is rebooting for a kernel update, your internet goes down with it — something a dedicated appliance wouldn't do. For a homelab, that's usually an acceptable trade. For anything closer to production, you'd want to think about whether that single point of failure is acceptable, or plan for a cluster with HA later.

Virtualized vs. Dedicated Firewall Appliance

Prerequisites

Before you start, you'll want:

• A working Proxmox VE 9.x host (the same steps apply to 8.x) with at least one spare physical NIC, or a managed switch capable of trunking VLANs to a single NIC if you're going the VLAN route instead
• The current OPNsense installer ISO, downloaded from opnsense.org/download and uploaded to a Proxmox storage that supports ISO images
• At least 2 vCPUs, 4GB of RAM, and 20GB of disk allocated for the VM — OPNsense runs comfortably on far less than most people assume, but leave headroom if you plan to enable IDS/IPS later
• A clear idea of your WAN and LAN address ranges before you start — decide this on paper first, not while you're mid-install
• Console access to the Proxmox host that doesn't depend on the network you're about to reconfigure — the built-in noVNC console in the Proxmox web UI is enough, since it doesn't route through the firewall VM you're building

One structural decision to make up front: are you dedicating a whole physical NIC to WAN, or using a single NIC with VLAN tagging to separate WAN and LAN traffic? Dedicating a NIC is simpler and what this guide assumes, but if you only have one NIC in the box, a VLAN-aware bridge with tagged sub-interfaces works too — just be aware that your upstream switch has to cooperate with the tagging.

Step-by-Step Tutorial

Part 1: Setting Up the Proxmox Bridges

You need two bridges: one carrying your real internet uplink (WAN) and one for your internal network (LAN). If you have two physical NICs, this is straightforward. SSH into the Proxmox host, or use the Shell button in the web UI, and open the network config:

nano /etc/network/interfaces

Your existing vmbr0 is likely already bridged to whichever NIC currently gives the host its own internet access. Repurpose that one as WAN, and add a second bridge for LAN using your other physical NIC:

auto vmbr0
iface vmbr0 inet manual
        bridge-ports enp1s0
        bridge-stp off
        bridge-fd 0
#WAN bridge - no IP on the host itself

auto vmbr1
iface vmbr1 inet static
        address 192.168.10.1/24
        bridge-ports enp2s0
        bridge-stp off
        bridge-fd 0
#LAN bridge - Proxmox host uses this for its own management IP

Note that vmbr0 here has no static address of its own — the Proxmox host doesn't need an IP on the WAN side at all, since OPNsense is the thing that will own the WAN connection once it's up. vmbr1, on the other hand, gets an address in the LAN range, because it's convenient for the Proxmox host itself to live on your internal network and be reachable at a normal LAN IP for management.

Apply the change:

ifreload -a

Important: if the Proxmox host currently manages itself over the interface you're about to turn into a bare WAN bridge, do this from the console, not over SSH — you're about to remove that interface's own IP address, and doing that over a connection riding on it will drop you instantly.

Part 2: Creating the OPNsense VM

In the Proxmox web UI, click Create VM. Use these settings, adjusting to taste but keeping the network and hardware choices below:

• General: give it a clear name like opnsense-fw
• OS: select the OPNsense ISO you uploaded, guest type Other
• System: machine type q35, BIOS can stay as SeaBIOS (OVMF/UEFI also works if you prefer it, but isn't required)
• Disks: Bus/Device VirtIO Block or SCSI with the VirtIO SCSI controller, 20GB is plenty for a homelab firewall
• CPU: 2 cores, type host for best performance
• Memory: 4096 MB, balloon device can be left on
• Network: first NIC bridged to vmbr0 (WAN), model VirtIO (paravirtualized) — do not pick the default Intel E1000 emulation, VirtIO is both faster and what this guide's checksum fix assumes

Don't start the VM yet. Go to Hardware on the new VM and click Add > Network Device to add the second NIC, bridged to vmbr1 (LAN), also set to model VirtIO. You should now have two network devices listed: net0 on vmbr0 and net1 on vmbr1.

While you're in Hardware, go to Options and disable the Proxmox Firewall checkbox on both network devices — running Proxmox's own firewall layer in front of a VM whose entire job is being a firewall just adds a second, redundant rule set that's easy to forget about and hard to debug through.

Part 3: Installing OPNsense

Start the VM and open its console. Boot into the installer and log in with the default installer credentials: username installer, password opnsense. Walk through the installer:

1. Select your keyboard layout (or accept the default)
2. Choose ZFS or UFS as the filesystem — ZFS is a reasonable default if you want snapshots inside the guest itself, UFS is lighter and perfectly fine for a firewall VM
3. Select the virtual disk you created (it will show up as a VirtIO block device)
4. Let the installer copy files and complete
5. When prompted, set a root password for the OPNsense web UI and console — don't skip this
6. Reboot when prompted, removing the ISO from the virtual CD drive first (in Proxmox, Hardware > CD/DVD Drive > do not use any media)

On first boot after install, OPNsense drops you into its console menu and asks you to assign interfaces. This is the step people most often get wrong. You'll see something like vtnet0 and vtnet1 listed — these correspond to your Proxmox net0 and net1 devices, in the order you added them. Assign:

• vtnet0 → WAN
• vtnet1 → LAN

If you're not sure which is which, the console menu lets you probe link state on each before committing — unplugging is obviously not an option for a virtual NIC, but you can check which bridge shows traffic in the Proxmox UI's network graph for each device while testing.

The installer sets a default LAN IP of 192.168.1.1/24. Either accept that or set it to match the LAN subnet you planned — in the example above, that would be something like 192.168.10.254/24, keeping it out of the way of the Proxmox host's own 192.168.10.1 address on the same bridge.

Part 4: Running the Web Setup Wizard

From a device on the LAN bridge (or the Proxmox host itself, since it's on vmbr1 too), browse to https://<LAN-IP> — accept the self-signed certificate warning, that's expected on first run. Log in with root and the password you set during install.

The setup wizard walks through:

• General Information: hostname, domain, and DNS servers — you can point these at your ISP's DNS or a public resolver like 1.1.1.1
• Time server: defaults are fine unless your network is fully isolated from the internet
• WAN interface: select DHCP if your ISP hands out an address automatically (the common case for cable/fiber with a modem in bridge mode), or PPPoE/Static if your provider requires it
• LAN interface: confirm or adjust the IP and subnet mask you set during install
• Root password: you can set it again here, or leave what you set during install

Finish the wizard and reload. At this point OPNsense should be actively routing — any device you connect to vmbr1 (LAN) should be able to get a DHCP lease from OPNsense and reach the internet through it, assuming your WAN side has a working upstream connection.

Part 5: Migrating the Rest of Your Network

With the firewall VM proven to work, move your other VMs and physical devices onto the LAN bridge (vmbr1) and let OPNsense's DHCP server hand out addresses, or set static IPs in the LAN range. Set the OPNsense VM to Start at boot in its Options tab, and set its Start/Shutdown order to a low number (like 1) so it comes up before any VM that depends on it for network access — Proxmox starts VMs in ascending order of this value.

Commands Explained

• bridge-ports enp1s0 — wires the bridge directly to a physical network card, making it the interface that carries traffic on and off the host.
• iface vmbr0 inet manual — tells Proxmox not to assign an IP address to this bridge itself; it exists purely to pass traffic through to the VM attached to it.
• ifreload -a — reapplies /etc/network/interfaces live using ifupdown2, without a full reboot, applying only what changed.
• vtnet0 / vtnet1 — the FreeBSD device names for VirtIO network interfaces, which is what OPNsense sees instead of the Proxmox-side net0/net1 labels.

Common Errors

• WAN shows a link but never gets a DHCP lease. Almost always means the WAN bridge (vmbr0 in this guide) isn't actually wired to a live physical uplink, or the modem upstream needs to be power-cycled to release its old DHCP lease/MAC binding from before you virtualized the firewall.
• LAN clients get an IP but can't reach the internet. Check the OPNsense WAN interface status first — if WAN itself has no address, nothing downstream will route. Also confirm the default outbound NAT rule under Firewall > NAT > Outbound is set to Automatic, which it is by default.
• Intermittent connection drops, corrupted downloads, or web pages that partially load. This is the well-known checksum-offload issue with VirtIO NICs under Proxmox/QEMU combined with FreeBSD-based guests like OPNsense and pfSense. The host offloads checksum calculation to hardware, but the virtual NIC path doesn't always do it correctly, producing packets FreeBSD considers corrupt. Fix it inside OPNsense under Interfaces > Settings, or via console option 8 (Shell) running:

  ifconfig vtnet0 -txcsum -rxcsum -tso -lro
  ifconfig vtnet1 -txcsum -rxcsum -tso -lro

  To make it persist across reboots, add hw.vtnet.csum_disable="1" to System > Settings > Tunables in the OPNsense web UI.
• Locked out of the web UI after a firewall rule change. The default LAN rule that allows all traffic is sometimes edited or replaced by accident. Recover via the OPNsense console menu (option 2, "Set interface IP address" won't fix a bad rule, but option 8 shell access lets you reset rules, or option 4 resets to factory defaults as a last resort).

Troubleshooting

Work from the Proxmox side first when something's not routing. Check ip a on the host to confirm vmbr0 and vmbr1 both exist and are up. Then check the VM's hardware tab to confirm net0 is actually attached to vmbr0 and net1 to vmbr1 — it's an easy thing to get swapped, especially if you added the second NIC after creating the VM and it landed on a different bridge than you intended.

Inside OPNsense, Interfaces > Overview shows link status and current IP for both WAN and LAN. If WAN shows no carrier, the problem is almost certainly on the Proxmox bridge or physical cabling side, not inside OPNsense. If both interfaces look correct but traffic still isn't flowing, check Firewall > Log Files > Live View while generating traffic from a LAN client — it'll show you exactly which rule (or lack of one) is blocking a given connection.

If you've locked yourself out entirely and the LAN interface itself won't respond, use the Proxmox noVNC console on the VM directly — it talks to the VM's virtual display, not through the network you've potentially broken, so it always works regardless of what state the firewall rules are in.

Best Practices

Take a Proxmox snapshot of the OPNsense VM before any change you're not fully confident about — a bad firewall rule or a botched interface reassignment is a thirty-second rollback with a snapshot, versus a potentially hours-long troubleshooting session without one.

Back up your OPNsense configuration separately from Proxmox snapshots too. System > Configuration > Backups lets you download a config.xml that captures every rule, alias, and setting — keep a copy somewhere off the host itself, since a snapshot only helps if the underlying Proxmox host is still alive.

Give the OPNsense VM guaranteed CPU priority if you're running it alongside CPU-hungry VMs — a firewall that gets starved of CPU time under host load turns into a very effective, very unintentional denial-of-service against your own network. A CPU limit isn't necessary, but avoid setting other VMs to a higher scheduling priority than the firewall.

If your host only has one physical NIC, seriously consider adding a second cheap NIC rather than running WAN and LAN through VLAN tags on a shared one. It's not required — VLAN tagging works — but a dedicated WAN NIC removes an entire class of "which VLAN is this traffic actually on" debugging sessions later.

Frequently Asked Questions

Can I use pfSense instead of OPNsense with this same setup?

Yes, the process is nearly identical — pfSense also ships VirtIO drivers and uses the same WAN/LAN bridge model. The checksum-offload fix applies there too, since it's a FreeBSD/VirtIO interaction, not something specific to OPNsense.

Do I really need two physical NICs?

No. A single NIC works if your upstream switch or modem can hand you a tagged VLAN for WAN, using a VLAN-aware bridge on the Proxmox side instead of a second physical bridge. It's more setup, and mistakes are harder to diagnose, so two NICs is the easier path if you have the option.

Will a virtualized firewall be noticeably slower than a dedicated appliance?

For typical home internet speeds (up to a few hundred Mbps), no — VirtIO networking with multiqueue enabled easily saturates a residential connection. It only becomes a real consideration at multi-gigabit throughput with heavy IDS/IPS inspection enabled, where dedicated hardware with offload capabilities pulls ahead.

What happens to my network if the Proxmox host reboots?

Everything routed through the OPNsense VM goes down until the host finishes booting and the VM starts again. Setting the VM's boot order to start early and enabling "Start at boot" minimizes the gap, but there will always be a short outage during host reboots or updates — this is the main tradeoff of virtualizing your firewall versus using dedicated hardware.

Can I run OPNsense in a Proxmox cluster with HA failover?

Technically yes, but CARP-style firewall failover (OPNsense's own high-availability feature, using two firewall VMs syncing state) is a more reliable approach than relying on Proxmox HA to migrate a single firewall VM between nodes, since Proxmox HA restarts a VM cold rather than failing over live. If uptime matters that much, look at OPNsense's built-in HA/CARP setup with two VMs instead.

Conclusion

Turning a Proxmox host into your router isn't a hack — it's a well-trodden path with VirtIO drivers built specifically to support it, and it buys you snapshot-based rollback that a physical firewall appliance can't match. The two things that separate a smooth setup from an afternoon of confusion are getting the WAN/LAN bridge split right before you touch the installer, and knowing about the VirtIO checksum-offload quirk before it shows up as mysteriously corrupted downloads three days later.

Once it's running, treat the firewall VM as the most important thing on the host: give it boot priority, snapshot it before changes, and keep a config backup outside of Proxmox entirely. From there, it behaves exactly like any other OPNsense install — the fact that it's virtual mostly disappears.