I've been looking at our hardware refresh cycle for the branch office firewalls and the usual rack-and-stack proposition for a Firebox M270 is, frankly, a bit painful. The idea of shifting to a virtual appliance model is appealing, especially if we can consolidate onto our existing Proxmox cluster and treat it like any other VM. The official stance from WatchGuard seems to be a predictable "supported on VMware, Hyper-V, and KVM," with the usual vendor caveats about support tickets requiring a blessed hypervisor.
So, naturally, I'm skeptical of the marketing that implies flexibility while the fine print giveth away. Proxmox is fundamentally KVM/QEMU under the hood, so in theory it should run. The theory, however, rarely accounts for the specific VirtIO drivers, the console behavior, or the way the virtual appliance might expect certain hypervisor flags to be set.
My question isn't just *can* you boot the OVA. I want to know if anyone has run this in production or a serious lab under Proxmox and lived to tell the tale. Specifically:
* Which Firebox virtual image version did you use, and what's your Proxmox version (e.g., 8.1.x)? The devil is always in the version matrix.
* Did you have to perform any unsupported contortions to get the image imported, or was a simple `qm importovf` sufficient? WatchGuard's OVA is just a wrapper, but I've seen some that include odd disk controllers.
* More importantly, how does the networking map? Proxmox's Linux bridge or OVS setup versus a vSwitch in VMware is a different beast. Did you assign the virtual interfaces as VirtIO (performance) or default to e1000 (compatibility)? Any issues with interface ordering or the management vs. external vs. trusted zones coming up correctly?
* Performance pitfalls? I'm particularly interested in IPS/Threat Detection throughput and any SSL inspection overhead. Does the virtual appliance seem to make efficient use of the pinned vCPUs, or does it feel like it's waiting on emulated hardware somewhere?
I've provisioned the template below based on a quick test, but it's the operational nuance I'm after. The last thing I need is a screaming ticket at 2 AM where WatchGuard support points at our "unsupported" hypervisor as the root of all evil.
```bash
# Example of the basic import process I used for a lab test
qm importovf 999 /path/to/watchguard-firebox.ova local-lvm --format qcow2
# Then manually adjusting the hardware: network to VirtIO, machine to q35, etc.
```
Any war stories or config snippets that move beyond the trivial would be appreciated. I'm less interested in "it pings" and more in "it handles a BGP peering session during an IPS update without falling over."
Trust but verify.
Good question. I've only run it in a test lab, never production. Used the Firebox v12.5.2 image on Proxmox 8.1.7.
It boots, but the network setup felt brittle. Had to use the e1000 NIC model, not VirtIO, and the noVNC console was required for initial config. Performance seemed fine, but I'd be nervous without a solid backup host to failover to.
Has WatchGuard ever pushed back on a support ticket just for being on Proxmox, or is it more of a generic disclaimer?
Your point about using e1000 instead of VirtIO is spot on. I ran into the same driver issue last year with v12.3. The initial config forced me to use the VGA console too, not serial.
On the support question, my experience is they'll handle a ticket on an "unsupported" hypervisor, but if the issue is at all related to the virtual environment, they'll immediately hit pause and ask you to reproduce it on VMware or Hyper-V. It's a hard stop. That's why I'd only consider this for a lab or a non-critical edge case.
Ship fast, measure faster.
The e1000 requirement is consistent with their officially supported platforms, I've seen the same on KVM. It's likely because the VirtIO drivers aren't built into their kernel image for the virtual appliance, a common limitation with these vendor-baked images.
On the support question, I've had them push back hard. It's not just a generic disclaimer. If you open a ticket, the first form response will ask for your hypervisor and version. If it's not on their short list, the ticket gets tagged as "unsupported environment" and any subsequent troubleshooting that points toward the virtual layer will be met with a request to replicate the issue on VMware ESXi. I've seen it escalate to a manager simply refusing to proceed until the environment was changed.
That said, for a lab or a non-mission-critical internal segment, Proxmox works well enough once you get past the initial NIC and console hurdles. Just don't expect any help from them if your virtual interfaces start dropping packets.
- Mike
>The theory does hold up, but the friction starts right at import. Proxmox doesn't natively handle the OVA format. You'll need to extract the raw disk image and descriptor file, then create the VM manually. It's an immediate red flag for easy lifecycle management.
You're right to focus on the version matrix. I've run the v12.5.x train on Proxmox 8.1.x. Network is the biggest gotcha: you must set the NIC model to e1000, and you'll need at least two separate bridges for the trusted/untrusted interfaces. The console only works properly via noVNC for initial setup; serial doesn't respond.
If this is for a branch office, I'd only consider it if you have identical, supported hypervisor hosts on standby for a rapid migration when support inevitably asks for it. Otherwise, you're buying a risk.
Show me the query.
I ran a pilot with the Firebox v12.5.2 image on a Proxmox 8.1.9 cluster for about three months in a non-production DMZ segment. The short answer is it boots and passes traffic, but the "KVM" support line in the marketing materials is disingenuous. WatchGuard's certified KVM refers to the Red Hat Enterprise Linux virtualization stack with specific kernel parameters and libvirt defaults. Proxmox uses a much newer QEMU version and a different set of default CPU flags (e.g., kvm64 vs. host). The e1000 NIC requirement is one thing, but the CPU model is the real trap.
We hit a recurring kernel panic on the firewall appliance whenever we applied a policy update that triggered a certain process in the kernel's network stack. The panic only happened under the `kvm64` CPU type. Switching to `host` (which exposes the full CPU feature set of the physical node) resolved it, but that's a flag WatchGuard's documentation explicitly warns against for VMware, because it breaks vMotion compatibility. On Proxmox, live migration is a non-starter anyway with the e1000 NIC, so the warning is moot, but it flags how brittle the environment is.
> "the way the virtual appliance might expect certain hypervisor flags to be set"
This is exactly the issue. The appliance probes for hypervisor-specific CPUID leaves and behaves differently depending on what it sees. With Proxmox's KVM, the appliance might not correctly identify the environment and disable certain features like the watchdog or hardware offloads. I never got a definitive answer from WatchGuard support because they stopped engaging after the third "please reproduce on ESXi" request.
If you go ahead, budget for a dedicated pair of Proxmox hosts just for this appliance, treat the NICs as pass-through if possible, and accept that any upgrade of either the hypervisor or the Firebox image will require a full re-test of the interconnect. Have you considered the throughput ceiling with e1000 vs. what the M270 hardware can push?