Running Sophos Firewall on Proxmox: what works well in the lab
Nathan Chadwick · · 2 min read
TLDRRead the short version
- Proxmox is a cheap way to learn Sophos Firewall (SFOS) with snapshots, cloning, and VLAN plumbing on one host. Treat it as lab or pilot, not a sizing exercise.
- Get images from Sophos or your partner portal, then either import and convert the virtual disk or boot the ISO installer on an empty VM.
- Size from Sophos minimums and add headroom for IPS, TLS inspection, and logging. Slow firewall usually means CPU for decryption or disk for logs.
- Map WAN, LAN, and DMZ to separate Proxmox bridges so the lab mirrors real topology, and pick one VLAN style rather than mixing trunks and bridges.
- First boot: finish the wizard on LAN, set admin, time zone, and DNS, license it, and export config backups off the hypervisor.
- When you outgrow the lab, rebuild cleanly on supported hardware or cloud images rather than migrating a tinkered disk.
Why Proxmox first#
Proxmox VE is a convenient place to learn Sophos Firewall (SFOS) without racking appliances: snapshots, cloning, and cheap VLAN plumbing on a single host. Treat it as lab or pilot, not a substitute for sizing, support, and hardware compatibility matrices unless Sophos explicitly supports your deployment model.
Get an image you can boot#
Sophos publishes software images for virtual deployments. Download the SFOS build that matches your licensing path (home lab vs commercial) from Sophos or your partner portal—do not use random ISOs from third-party mirrors.
Typical approaches on Proxmox:
- Import a virtual disk format Proxmox understands (often via qemu-img convert from VMDK/OVA extraction), or
- Boot the ISO installer on a fresh empty VM and run the text/GUI installer like bare metal.
If you start from OVA, unpack it, convert disks to qcow2, attach them to a new VM, and match virtio drivers where the installer supports them for better performance.
Size the VM like a small appliance#
Start from Sophos minimum guidance for vCPU, RAM, and disk for your version, then add headroom if you enable IPS, TLS inspection, or heavy logging. Under-sized VMs feel like “the firewall is slow” when the bottleneck is CPU for decryption or disk for logs.
- Disk: thin or thick qcow2 on fast storage; log-heavy labs need more than you think.
- NICs: plan WAN, LAN, and DMZ as separate Proxmox bridges (
vmbr0,vmbr1, …) so you can mirror real topology instead of single-segment NAT tricks.
Networking that will save you pain#
- Linux bridges on the Proxmox host map to Sophos interfaces. Label them in your head the same way you will in Azure or on hardware later.
- Use VirtIO network devices if the SFOS build supports them well on your version—fallback to E1000 only if you hit driver quirks during install.
- For VLANs, either trunk into Proxmox and tag on the Sophos side, or attach multiple bridges—pick one style and stay consistent.
First boot checklist#
- Complete initial setup wizard on LAN access (browser to the management IP).
- Set admin credentials, time zone, and DNS before you bolt on features.
- Register or license according to your entitlement—unlicensed behaviour varies by feature.
- Take a Proxmox snapshot only after the appliance is cleanly shut down if your storage supports quiescing; otherwise snapshot-aware backups are safer for production-like tests.
Lab habits that translate to production#
- Document every interface mapping (Proxmox bridge → Sophos port → VLAN purpose).
- Export configuration backups from Sophos on a schedule and store them off the hypervisor.
- When you outgrow the lab, rebuild on approved hardware or cloud images rather than blindly migrating a tinkered disk—clean installs reduce mystery gremlins.
What this post is not#
It is not a substitute for Sophos release notes, support, or your compliance requirements. Always validate virtual deployment guidance against the current SFOS documentation for your build.
References#
Sources and further reading for the claims above.