Running a Firewall on Proxmox: Reboots, Downtime & Recovery

Quick Answer

To reduce downtime caused by reboots and ensure fast recovery when failures occur, the key is not to “avoid rebooting,” but to design a clear recovery path in advance:

1. Ensure the Firewall VM supports automatic startup, and configure a proper boot order and delay so that core network services recover first;

2. Keep an independent Proxmox management access method (such as a dedicated management NIC or local console access) so you are not fully dependent on the firewall to enter the system;

3. Prepare a clear recovery process and backups in advance (VM backups + firewall configuration backups + network topology records), so that when a network outage happens, you can quickly roll back and troubleshoot step by step.

1. What Happens to the Firewall When the Proxmox Host Reboots?

If OPNsense or pfSense is running on a Proxmox host, a host reboot will temporarily interrupt the Firewall VM.

The recovery sequence is typically:

Proxmox Host → Firewall VM → Firewall Services → LAN / Internet

Because of this dependency, the Firewall VM should not rely on manual startup.

Proxmox supports automatic VM startup on boot, and also allows configuring startup order and delay.

For a firewall host, a reasonable startup order is:

1. Firewall VM

2. DNS / AdGuard

3. Monitoring

4. Other application VMs

This ensures that services depending on the gateway or DNS do not start before the underlying network is ready.

2. How to Reduce Downtime Risk in a Proxmox Firewall Setup

Enable Automatic Startup

Make sure the Firewall VM is configured to start on boot. Otherwise, after a host reboot, Proxmox may be online but the LAN could still have no internet access.

Keep Proxmox Management Independent

Do not make access to Proxmox entirely dependent on the firewall VM.

Practical options include:

• Dedicated management NIC

• Independent management network

• Local console access

This ensures that even if the OPNsense VM does not start, you can still access the host for troubleshooting.

Avoid Unnecessary Host Network Changes

If this machine acts as the main gateway, avoid repeatedly testing:

• Bridge changes

• VLAN changes

• PCI passthrough experiments

• NIC reconfiguration

directly on a production network.

Before making changes, you should at least ensure:

You have console access, backups, and a rollback plan.

3. What to Check Before Rebooting or Updating Proxmox

Before performing maintenance, quickly verify the following items:

This checklist is more important than simply knowing “Proxmox reboot may cause network downtime.”

Spending a few minutes verifying these items before maintenance is usually far more effective than troubleshooting after a failure occurs.

4. What to Check First When the Firewall VM Does Not Recover After Reboot

Do not immediately start changing settings inside OPNsense.

A more effective approach is to troubleshoot layer by layer.

Step 1: Check the Proxmox Host

First confirm:

• The host has booted successfully

• Storage is properly mounted

• Proxmox management interface is accessible

If the host itself is not functioning correctly, checking the firewall VM is meaningless.

Step 2: Check the Firewall VM

Verify:

• Whether the VM has started

• Whether there are boot errors

• Whether CPU / RAM / disk resources are normal

• Whether you can access the VM console

Step 3: Check NIC, Bridge, or Passthrough Configuration

Then verify:

• Whether the WAN NIC is mapped correctly

• Whether the LAN bridge exists

• Whether PCI passthrough devices are functioning

• Whether NIC assignments were recently changed

If the host and VM are both running but there is no network connectivity, this layer is often the cause.

Step 4: Check the Firewall OS

Inside OPNsense or pfSense, check:

• WAN interface

• LAN interface

• Interface assignments

• DHCP status

• Gateway status

Step 5: Check WAN and LAN Connectivity

Finally confirm:

ISP / Modem → Firewall WAN → Firewall LAN → Client

Identify exactly which segment has failed to recover.

Following this order helps avoid modifying multiple layers at once, which can make the problem harder to diagnose.

5. What to Prepare for Backup and Recovery

Backups do not eliminate downtime, but they significantly reduce recovery time.

Proxmox VE’s built-in backup system stores VM configuration and data and supports later restoration.

For a firewall host, you should at least keep:

• Proxmox VM backups

• OPNsense / pfSense configuration backups

• NIC assignments

• Bridge configurations

• VLAN information

• WAN settings

It is best not to store both firewall configuration backups and VM backups only on the same host SSD.

If the host storage fails, backups should still remain accessible.

6. Real-World Limitations of a Single-Node Proxmox Firewall

A setup running:

Proxmox + Firewall VM on a single mini PC

is still a single-node architecture.

If the host itself fails, the firewall will not automatically fail over to another machine.

True Proxmox High Availability belongs to a cluster architecture; Proxmox officially recommends at least three nodes for a reliable quorum.

For most home labs, the realistic goal is not to build full HA for occasional short maintenance windows, but to:

• Configure automatic startup

• Maintain independent management access

• Keep recoverable backups

• Document network configuration

• Accept planned short maintenance downtime

If your internet connection cannot tolerate this level of host downtime, a dedicated bare-metal firewall is often simpler.

The Key Point of Managing a Proxmox Firewall Is Not “Zero Downtime”

For a single-node home lab, completely eliminating downtime caused by host maintenance is not realistic.

What is actually worth doing is:

Making downtime predictable, ensuring automatic recovery, and guaranteeing you can still access the host when something goes wrong.

If you know what to check before a reboot, and you know the correct troubleshooting order when the firewall does not come back, then running a firewall on Proxmox shifts from “uncontrolled risk” to a manageable operational trade-off.

Related Guide: Bare Metal vs Virtualized Firewall

Related Guide: Proxmox Firewall Hardware Requirements

Related Guide: OPNsense on Proxmox: Virtual Bridge vs PCI Passthrough

Explore CWWK Firewall Hardware →