Sophos Firewall: Hardware, virtual or cloud?

Sophos Firewall can be operated as an XGS Appliance, virtual appliance, Software Appliance or Cloud Deployment. All variants run Sophos Firewall OS, but the operating model is not the same. The decision affects performance, support, port design, HA, recovery, licensing, monitoring and the question of who is responsible for which platform in the event of a disruption.

For new projects, you shouldn’t just ask which variant is cheaper. What matters is which variant suits the location, the virtualization platform, the cloud architecture and the operations team. The Sophos Firewall Sizing Guide is also important for performance sizing.

The platform choice also determines compliance features: FIPS 140-3 mode is available on XGS Appliances, supported virtual platforms, AWS, and Azure, but not on software appliances or XG and SG hardware.

Choose the Operating Model

Quick decision

• XGS Appliance: Mostly suitable when a location needs a dedicated, clearly supportable firewall with physical ports.
• Virtual Appliance: Mostly suitable if a stable virtualization platform is available and network zones can be cleanly separated virtually.
• Software Appliance: Usually suitable if your own hardware is to be deliberately operated and supported as a firewall platform.
• Cloud Deployment: Most often suitable when protecting workloads in AWS or Azure or connecting them to local networks.

The most important rule: A virtual or cloud firewall is not a free pass for less planning. CPU, RAM, storage, virtual switches, routing, HA, backup and monitoring must be planned just as carefully as with hardware.

When to be careful

The decision should not just be based on what is technically possible. Some environments look flexible on paper, but create unnecessary risks in operation.

• Hypervisor is already heavily utilized: IPS, TLS Inspection, VPN and logging need predictable CPU and I/O reserve.
• WAN, LAN, DMZ and management run through the same physical bottleneck: A logically clean separation is of little help if the real data path is overloaded or incorrectly segmented.
• No team feels jointly responsible for hypervisor and firewall: Incidents remain between platform, network and firewall teams.
• HA was only planned as a checkbox: Without host, storage, network and restore testing, high availability is not proven.
• Cloud routing is not fully documented: The firewall only protects traffic that is actually routed through it.
• Restore was never practiced: A backup is only reliable if a restore has been realistically tested or at least properly planned.

In such cases, an XGS Appliance is often no less modern, but simply the more robust operational decision. Conversely, a virtual or cloud firewall can be very useful if the platform, network design, monitoring and responsibilities are clearly clarified.

Compare the Platforms

XGS Appliance

An XGS Appliance is usually the most predictable option for traditional sites. Hardware, ports, support, RMA, lifecycle and firewall OS come as a coordinated system.

Sophos offers physical hardware for requirements ranging from home users and small businesses to large enterprises. The right XGS Appliance depends on traffic, security features, ports and HA requirements. If needed, ask Sophos sales or a partner to review the selection against those requirements. Suitability for a home network does not automatically mean that the free Home license can be used on the chosen hardware.

Advantages:

• dedicated firewall hardware,
• fixed network-port configuration and expansion options,
• clear assignment of WAN, LAN, DMZ, HA link and management,
• easy hardware support and replacement process,
• no dependency on hypervisor resources,
• Well suited for branches, headquarters and edge firewalls. The biggest advantage lies in operation: If there is a problem, you don’t have to first clarify whether the hypervisor, vSwitch, storage, cloud routing or firewall itself is the cause. For many SME locations, this is more important than maximum flexibility.

Virtual appliance

A virtual Sophos Firewall makes sense if a clean virtualization platform already exists and the firewall is to be integrated into a data center, a multi-tenant environment or an internal segmentation design.

It provides SFOS security features from hardware appliances in virtualized form, including identity-based security. This takes user identity into account in security decisions, rather than only the network address. Organizations and Managed Security Service Providers (MSSPs) can consolidate network protection for virtual data centers or offices on a virtual firewall. The available features depend on licensing and the supported platform; this does not imply identical hardware acceleration or the same throughput as an XGS Appliance.

Virtual and cloud deployments with SFOS can also use Sophos Endpoint Security Heartbeat to take the health of managed endpoints into account in access decisions. This requires appropriate endpoint and firewall licence entitlements, registration in the same correct organisation, and an explicitly configured response. Identity-based security is not an equivalent mechanism for assessing endpoint health; registration alone demonstrates neither isolation nor the blocking of all traffic paths. The guide to Security Heartbeat and Synchronized Security explains the prerequisites, response paths and checks to verify their effects.

Sophos also offers centralized management of Sophos Firewall devices. The SFOS 22 platform overview calls this Sophos Fusion (previously Sophos Central), while the SFOS 23 overview uses Sophos Central. These different names do not establish that centralized management was introduced with SFOS 23. When planning deployment, check the service used in your management portal and its firewall onboarding requirements; centralized log analysis alone is not centralized device management.

Relevant virtual platforms include VMware, Microsoft Hyper-V, KVM, Nutanix Prism, and Citrix Hypervisor. Before deployment, verify the specific platform version against the current Sophos compatibility information. Sophos states a minimum of one vCPU, 4 GB RAM, two vNICs, a 32 GB primary disk, and an 80 GB report disk. These are installation minimums, not a sizing recommendation for production inspection traffic.

The platform check must go beyond the product family. For Nutanix, for example, Sophos specifies AOS 6.5.x or a later LTS release, the AHV version bundled with it, a compatible Prism Central version, and an AHV cluster registered with Prism Central. KVM requires an x86 host with a recent Linux kernel and enabled Intel VT or AMD-V support. If you increase vCPU and RAM for a higher load, also plan a larger report disk for the additional log volume.

Important operational questions:

• Are CPU resources guaranteed or heavily oversubscribed?
• Are RAM and storage sufficiently dimensioned?
• Are virtual NICs and port groups clearly separated?
• Are there dedicated network paths for WAN, LAN, DMZ, HA and management?
• Is promiscuous mode, VLAN trunking or SR-IOV required?
• Is there a clean backup and restore concept?
• Is it clear who troubleshoots the hypervisor, storage and firewall together?

A virtual firewall can work very well. However, things quickly become problematic when it runs on an overloaded host or when WAN, LAN and management only look logically clean, but physically run through the same bottlenecks.

⚠️ Hypervisor snapshots or backups from the virtualization vendor are not a supported replacement for the integrated Sophos backup. For a supported restore, save the configuration under Backup & Firmware > Backup & Restore. Platform backups may exist in addition, but they must not be the only recovery path.

Software Appliance

A Software Appliance is installed on dedicated x86-64 hardware. This can be useful for labs, special environments, or highly targeted designs. In normal customer operations, choose this model deliberately because hardware selection, drivers, spare parts, monitoring, and support are largely the operator’s responsibility.

SFOS on suitable physical hardware provides firewall rules and policies, threat response, and static, SD-WAN and dynamic routing, subject to the relevant licenses and platform sizing. Manufacturer names such as Dell or HP are examples, not a verified model-by-model compatibility list.

The installation reformats and repartitions the disk, deleting the existing operating system and all files. For an SFOS 22 Software Appliance, Sophos requires Legacy BIOS, at least 4 GB RAM, two network interfaces, and at least 32 GB storage; 64 GB is recommended. If the minimum requirements are not met, the firewall can enter fail-safe mode.

Conflicting storage figures: The SFOS 22 and 23 platform overviews state a 10 GB minimum for custom hardware. The specific SFOS 22 Software Appliance installation requirements instead specify at least 32 GB and recommend 64 GB. This guide deliberately follows the more specific, conservative requirement for installation: at least 32 GB, with 64 GB recommended. Do not plan an installation with 10 GB; also check the requirements for your chosen SFOS version before installing. This discloses the documentation conflict, rather than claiming to resolve it through a device test.

If an appliance already starts in Failsafe mode, record the cause detected by SFOS with the Check Sophos Firewall in Failsafe mode runbook before changing resources.

Check:

• Is the hardware suitable for continuous operation?
• Are network cards, storage and BIOS/UEFI configuration suitable?
• Is there replacement hardware?
• Is the installation and recovery process documented?
• Who is responsible for hardware errors?

For standard locations, an XGS Appliance is often easier. For technical special cases, a Software Appliance can still be suitable if the operations team has a good command of the platform.

Cloud Deployment

Cloud deployments are particularly useful when workloads in AWS or Azure need to be protected or when cloud networks are connected to local locations. Different questions are important in the cloud than at the traditional location.

Plan:

• VPC/VNet design,
• routing tables,
• Availability Zones,
• Elastic IPs or Public IPs,
• Site-to-Site VPN or SD-WAN,
• Logging and central evaluation,
• Cloud costs for instance, storage, traffic and HA design,
• Operational responsibility between cloud team and firewall team.

A cloud firewall is not a replacement for clean cloud network design. Only the paths that are actually routed through the firewall are protected. The deployment and routing decisions are covered in the guides for Sophos Firewall on AWS and Sophos Firewall on Azure.

Install a virtual or software appliance

Download the image directly from the Sophos Firewall Installers page. Under Virtual Installers, choose the corresponding OVF package for Citrix or VMware, the VHD package for Hyper-V, or the QCOW2 package for KVM, Proxmox, or Nutanix. For custom hardware, use the ISO under Software Installers instead.

Before importing, verify that you loaded the download page linked above over HTTPS, obtained the package without a third-party mirror, and extracted the archive completely without errors. Keep the manifest, OVF, and both VMDK files together for an OVF package. If the import reports a manifest or checksum mismatch, stop and download the package again directly from Sophos. For an internal file transfer, you can also record a SHA-256 value immediately after downloading and compare it again on the target system. This detects transfer errors but doesn’t replace a vendor signature.

The minimums before importing are 1 vCPU, 4 GB RAM, two vNICs, a 32 GB primary disk, and an 80 GB report disk. Insufficient resources trigger fail-safe mode. Check the purchased CPU/resource entitlement before changing allocations; these minimums are not production sizing. Increase report-disk capacity when additional CPU/RAM enables more log volume. Hypervisor snapshots and vendor backup tools aren’t supported firewall backups; use the SFOS backup function.

The following paths describe the retained installation workflows, not a claim of laboratory, device, licensing-effect, or rollback tests on your particular platform/SFOS combination. Check current platform, operating-system, management-tool and image support first. Validate on a new isolated VM before routing production traffic. Keep the existing firewall and production routes unchanged until acceptance.

The platform overviews for SFOS 22 and 23 also list XCP-ng-Center as an alternative management tool to XenCenter for the Citrix family, and VMware Workstation as an alternative to the ESXi/vSphere deployment path described here for VMware. These listed options do not confirm current support or provide blanket approval for all XCP-ng versions. Before choosing either alternative, support for the exact host, platform and management tool versions must be confirmed. If support remains unclear, stop the deployment and use a demonstrably supported path. The following XenCenter and ESXi/vSphere steps are not installation instructions for these alternatives; in particular, do not reuse the ESXi workflow as a Workstation recipe.

Citrix Hypervisor and XenCenter

Prerequisites: Citrix Hypervisor is already installed on a reachable host, and XenCenter is installed on the management device. Verify supported host/OS/tool versions and save the extracted Citrix OVF package where XenCenter can read all its files.

1. In XenCenter, right-click the intended resource and select Import > Browse. Select the OVF, click Open, then Next.
2. Under Import VM(s) to, select the destination or specify a Home Server, then Next. Select the storage repository for both disks.
3. Map the network interfaces deliberately: PortA to the isolated admin/LAN network, the WAN-facing adapter to the separate intended WAN/test network. Do not expose factory WebAdmin to the internet.
4. Verify manifest content is optional in the import wizard; retain the manifest and investigate any mismatch rather than bypassing it. Continue with Next. Under OS Fixup Settings, keep Don’t use Operating System Fixup selected.
5. Review the summary and click Finish. Confirm successful import, both disks and both intended NIC mappings before right-clicking this new VM and selecting Start. Open its console, then follow the shared first-access procedure below.

VMware ESXi and vSphere Client

Prerequisites: the server already runs a currently supported ESXi release, and the administrator has a working, network-reachable vSphere Client management session. Extract the VMware package on the management device. Old virtual hardware-version labels do not establish current support for ESXi 4 or 5.

Select the OVF template deliberately:

• sf_virtual and sf_virtual_vm7: legacy hardware version 7, PCNet32 (Vlance), virtual link descriptor 10 Mbps, half duplex, fixed.
• sf_virtual_vm8: hardware version 8, E1000E, 1000 Mbps, full duplex, auto-negotiation On.
• sf_virtual_vm8_paravirtual: hardware version 8, VMXNET 3, 10000 Mbps, full duplex, auto-negotiation Off. Use E1000E as the documented fallback if the VMXNET 3 driver fails in your deployment.
• sf_virtual_virtualbox is not a VMware template. The link descriptors above are virtual-adapter characteristics, not firewall throughput guarantees.

1. In vSphere Client, right-click the deployment location and select Deploy OVF Template > Local file > Choose files. Select the chosen OVF together with sf_virtual-disk1.vmdk, sf_virtual-disk2.vmdk, and sf_virtual.mf; click Open > Next.
2. Enter name/location, select the compute resource and review the details, advancing with Next.
3. Select the datastore and virtual disk format. Thick Provision Lazy Zeroed allocates space at creation and zeroes blocks on first write. Thick Provision Eager Zeroed allocates and zeroes space at creation, which may take longer. Thin Provision allocates as needed to save space; monitor actual datastore capacity. Neither a disk-format description nor this procedure establishes support from Sophos for Fault Tolerance or a universal disk-conversion restriction.
4. Map both source networks deliberately, with PortA on the isolated admin network. Review the complete configuration and click Finish. Wait for successful deployment; inspect both disk sizes and connected NIC mappings.
5. Select Actions > Power > Power on, open the console and follow the shared first-access procedure.

Hyper-V Manager

Prerequisites: a supported Hyper-V host and Hyper-V Manager on a management device with network access to it. Extract the Hyper-V package and place both VHD files in storage accessible to the host; a path visible only on the administrator’s PC is not sufficient for a remote host.

1. Open Action > Connect to Server, then Action > New > Virtual Machine. In the wizard choose name/location, Generation 1, and Startup memory of at least 4096 MB.
2. Choose the isolated admin virtual switch for the first adapter. Select Use an existing virtual hard disk > Browse > PRIMARY-DISK.vhd > Open. Review and Finish; do not start yet.
3. Right-click the new VM, open Settings, and under Hardware select Network Adapter > Add. Map this second adapter to the separate planned network and click Apply.
4. Select SCSI Controller > Hard Drive > Add > Virtual hard disk > Browse, select AUXILIARY-DISK.vhd, then Open > OK. Verify the primary boot disk, auxiliary SCSI disk and both switches/sizes.
5. Right-click the VM and select Connect; start it from the console. Follow the shared first-access procedure.

KVM and Virtual Machine Manager

Prerequisites: an x86 Linux host with a recent kernel and enabled Intel VT or AMD-V, plus installed, accessible Virtual Machine Manager or suitable supported KVM management tools. Run these read-only checks on the Linux host, not in the SFOS console:

grep --color vmx /proc/cpuinfo
grep --color svm /proc/cpuinfo

Expect matching vmx flags for Intel or svm for AMD, not necessarily both. If the relevant check has no matches, stop and check CPU capability, firmware virtualization settings and, for a nested host, feature exposure. Visible flags alone do not prove firmware enablement or a working KVM deployment. #!sh in older guidance is a formatting marker, not a command prefix.

1. Extract the KVM archive. Open File > New Virtual Machine > Import existing disk image > Browse, choose PRIMARY-DISK.qcow2 with Choose volume, then Forward.
2. Set Memory (RAM) to at least 4096 MB and CPU to at least 1, within entitlement and sizing. Select Customize configuration before install > Finish. Enter a name and Apply.
3. Select the first NIC’s Network source as the isolated admin network. The retained example uses Device model > Hypervisor default; verify the resulting supported adapter, then Apply. Do not choose an unsegmented shared WAN/LAN bridge.
4. Select the primary disk, shown initially as IDE Disk 1, then Advanced options > Disk bus > VirtIO > Apply.
5. Select Add Hardware > Network, choose the separate planned network and Device model > virtio > Finish.
6. Select Add Hardware > Storage > Select or create custom storage > Manage. Choose AUXILIARY-DISK.qcow2 with Choose volume, set Disk bus > VirtIO, then Finish.
7. Verify both disks/buses/sizes and NIC mappings before Begin Installation. Select the firewall and Open its console; follow the shared first-access procedure.

Proxmox VE: directory-storage workflow

This path-based procedure applies to suitable directory storage, not arbitrary LVM, ZFS or Ceph backends. Inspect /etc/pve/storage.cfg first to identify the actual storage ID, backend and path. If your backend cannot use these QCOW2 file paths, stop and obtain the appropriate supported import procedure; do not paste directory examples into it.

1. Select the server and Create VM. Enter Name, select Do not use any media, choose environment-appropriate System, Hard Disk and CPU settings, and set Memory (MB) to at least 4096. Machine, SCSI Controller and Cache defaults are example-specific, not universal requirements.
2. Select the isolated admin Bridge. Leave Start after created unchecked, review and Finish. Record the VMID and confirm this is the new, unused test VM.
3. Open the host’s >_ Shell with appropriate privileges. Keep only this new VM stopped, preserve a copy of /etc/pve/qemu-server/<vmid>.conf, and record its existing disk mapping. Never delete or replace a production disk. /var/lib/vz/images/108/ is only an example directory for VMID 108; use the path belonging to your confirmed storage and VMID.
4. Transfer the actually downloaded KVM archive into that directory and extract it, for example with unzip ACTUAL_DOWNLOADED_ARCHIVE.zip after substituting the real filename. Expect PRIMARY-DISK.qcow2 and AUXILIARY-DISK.qcow2; a historical build filename is not a current-download instruction.
5. Open /etc/pve/qemu-server/<vmid>.conf in a text editor. On this stopped disposable VM only, replace its initial scsi0 mapping and add the auxiliary mapping. The retained example syntax is:

scsi0: vmdisk:<vmid>/PRIMARY-DISK.qcow2,size=32G
scsi1: vmdisk:<vmid>/AUXILIARY-DISK.qcow2,size=80G

Replace vmdisk with the confirmed directory-storage ID and <vmid> with the actual VMID; these are not literal working values. The size labels do not resize an undersized image. Verify the actual images meet the minimum sizes and that no existing scsi1 mapping is overwritten.

6. In Hardware, verify both disk slots, sizes and primary boot disk. Use Add > Network device to add the second NIC on the deliberate separate Bridge. Under Options, keep QEMU Guest Agent off. Recheck mappings before Start and opening the console.
7. If the edit is wrong, keep the new VM powered off and restore its saved configuration after rechecking VMID/storage identity. Do not remove the original disk file as part of this rollback. This local reversal is a pre-production procedure, not a tested production recovery. Follow shared first access only after the corrected hardware checks succeed.

Nutanix Prism Central

Prerequisites: AOS 6.5.x or a later LTS release, its bundled AHV, a compatible Prism Central (PC), and the AHV cluster registered to PC. The platform guidance specifies the Partner VA’s latest GA (LTS) release: GA means General Availability and LTS means Long-Term Support. Verify the actually supported partner-appliance release and platform combination; an SFOS 23 help page does not by itself identify the latest GA. Confirm licensed CPU resources, at least 4 GB RAM, two NICs and 32 GB/80 GB disks.

1. Extract PRIMARY-DISK.qcow2 and AUXILIARY-DISK.qcow2 from Virtual Installers: Firewall OS for KVM on the management device.
2. In PC, open Virtual Infrastructure > Images > Add Image > Add File. Add each file with Image Type > Disk. Click Next, select Placement Method and Select Clusters for your target, then Save. Refresh after upload and verify both images are available.
3. Open Infrastructure > VMs > Create VM. Under General Configuration, set name/timezone; under Compute Details, set entitled CPU and sufficient RAM. Under Disks, remove the default CD-ROM on this new VM only.
4. Select Add New Disk > Operation > Clone from Image Service > Bus Type > SCSI > Image > PRIMARY-DISK.qcow2 > Add. Repeat for AUXILIARY-DISK.qcow2 as the log disk; the retained auxiliary example also uses SCSI. Do not transplant the KVM VirtIO bus instructions here.
5. Under Network Adapters (NIC) > Add New NIC > VLAN Name, select the isolated admin VLAN and Add. Repeat for the separate intended second network. The source’s DHCP connectivity option is optional; plan stable interface addressing afterward. A VLAN selection is not itself an IP address.
6. Under VM Host Affinity > Set Affinity, select an approved host and Save, then save the VM. Expect a success message; inspect both disks, buses/sizes and NIC mappings before power-on.
7. Power on the new VM and select Launch console. Follow the shared first-access procedure.

First access, validation and safe reversal

Before first power-on, verify PortA and PortB against management, LAN and WAN networks. Reversed mappings can expose WebAdmin directly to the internet. In the isolated initial environment only, the documented factory administrator account/password is admin / admin; the console prompts for administrator password admin. Open https://172.16.16.16:4444 from the isolated admin client, for example 172.16.16.2/24. Review and accept the Sophos End User Terms of Use and click Start setup for registration/basic setup. Replace factory credentials during setup before any exposure, then follow getting started.

Do not change the default password in the CLI before the assistant: it will not start afterward. If this already happened, complete basic setup manually; do not reset a configured firewall simply to recover the wizard. Factory reset destroys configuration and is only a deliberate option for a protected disposable new VM with no configuration to retain.

Before production cutover, verify the license/serial number, normal console boot, both disks and reporting, interfaces/zones, supported SFOS backup, and a negative WebAdmin access test from an unauthorized network. These are checks for the operator to perform, not effects claimed to have been tested here.

If WebAdmin is unreachable, do not immediately reinstall. Check the client is directly on PortA’s network, the vNIC is connected and the port group/bridge actually maps to the isolated admin network. Confirm complete boot in the console and rule out a 172.16.16.16 address conflict. PortA must not be on the public WAN. Missing reports or fail-safe mode require checking report-disk assignment, bus/size, CPU/RAM and both vNICs; record the detected cause with the fail-safe runbook before changing resources.

If you decide to withdraw the new deployment before go-live, while no production traffic is routed through the new VM, power it off, reverse test routes and temporary gateways, and continue using the unchanged existing firewall. These steps apply only to rollback, not to a successfully validated production cutover. After go-live, recovery requires a current SFOS backup and documented rebuild, not a hypervisor snapshot; use the backup and restore procedure.

Software appliance on custom hardware

The target requires x86-64, Legacy BIOS, at least 4 GB RAM, two NICs and a 32 GB HDD/SSD (64 GB recommended). The USB needs at least 1 GB. Windows/macOS is the media-writing workstation, not an operating system retained alongside SFOS. Use the Software Installers: Firewall OS Software ISO for Intel Hardware download, extract the archive and verify the SW ISO and transfer integrity as above. Do not use an HW/XGS image or virtual disk package.

⚠️ Writing media erases the entire selected USB device. Installation then formats and repartitions the target server disk, deleting its previous OS and all data. Before either action, identify the exact device by capacity and device identity, save data externally and verify an independent restore path. Stop if the target is ambiguous. There is no automatic undo after installation; recovery needs separately saved original-system media/data, or a compatible SFOS backup with its password and associated SSMK.

Windows: Win32 Disk Imager

1. Insert the USB and identify its drive letter, capacity and device identity in Windows disk management; disconnect unrelated removable drives where practical. Obtain and start Win32 Disk Imager on the workstation.
2. Its file picker normally filters IMG files. Change the filter to *.* and select the extracted Sophos SW .ISO file.
3. Select the confirmed USB destination, not a system/data disk. Recheck the selected file and drive against your recorded identity, then Write and confirm the erase warning. Wait for successful completion and safely eject. Copying the ISO as a normal file does not create bootable media.

macOS: native media-writing alternative

1. Use Disk Utility to identify the external USB by capacity/device identity. Older instructions show Partitions > Volume scheme: 1 partition > Format: Free Space > Apply; these controls are version-specific and may not exist on your macOS release. Do not invent an equivalent or format another disk to reproduce that old UI. The reimage guide’s media-writing procedure is an alternative, using the SW ISO here rather than its hardware image.
2. In Terminal, go to the ISO directory. Replace SOPHOS_ISO with the actual downloaded filename before running:

hdiutil convert -format UDRW -o sf.img.dmg SOPHOS_ISO

3. Expect the converted sf.img.dmg. Run diskutil list, identify the whole external USB disk again, and unmount its volumes before raw writing (Disk Utility Unmount, not eject). Stop if you cannot identify or unmount the intended device.
4. The following is a template, not a paste-ready command. Substitute PATH_TO_USB with the confirmed whole-device path, never a partition or an assumed disk number. It erases that entire device:

dd if=./sf.img.dmg of=PATH_TO_USB bs=1m

Use sudo only if required for device permissions after rechecking the target. A raw path adds r to the confirmed device name (/dev/diskN becomes /dev/rdiskN); N is a placeholder, not a disk number to copy. Raw access may be faster but does not make the operation safer. Wait for the command prompt and successful completion; flush pending writes with sync and safely eject the USB before removing it. On error, stop rather than installing from an unverified write.

Install and check the physical server

1. Schedule downtime, preserve the existing firewall path and external backups, verify Legacy BIOS/USB boot and the exact installation disk. Disconnect unrelated data disks where feasible. Attach local monitor/keyboard and an appropriate serial console if needed.
2. Boot the prepared USB. Before typing y and pressing Enter at the installer confirmation, recheck server/disk identity and confirm all previous OS/data can be lost. If the installer target is unclear, stop. Follow the prompts to completion, remove the USB and restart; first boot can take a few minutes. Do not apply XGS LED instructions to this generic server.
3. Verify detected NICs and identify the management interface before connecting the isolated admin client at 172.16.16.2/24. Confirm normal boot and use https://172.16.16.16:4444, Terms of Use and Start setup as described above. Harden credentials, complete registration/licensing, and save an external SFOS backup before cutover.
4. If USB does not boot, check that it was imaged rather than file-copied, the SW image identity and Legacy BIOS/USB boot selection. For missing NICs/fail-safe, record the console cause and check minimums/driver compatibility before reinstalling. For unreachable WebAdmin, check management-NIC identity, link, client address, full boot and address conflicts; never connect factory management to public WAN as a shortcut. Use the internal fail-safe guide, getting-started guide and backup/restore guide for the next decision.

No USB write, destructive installer action, physical-device deployment or restore is claimed to have been performed for this documentary guide.

Plan Operations and Recovery

Performance and sizing

When it comes to hardware, performance depends on the model you choose. For virtual, software, and cloud deployments, performance is more platform dependent.

Particularly relevant:

• CPU performance and CPU reservation,
• RAM,
• storage latency,
• virtual NICs,
• hypervisor or cloud network path,
• number of sessions,
• TLS Inspection,
• IPS,
• VPN throughput,
• Logging and reporting. Data sheet values ​​should therefore always be read in context. Firewall throughput without security inspection is not the same as threat protection, TLS Inspection or IPsec VPN under real load. The guide to interpreting Sophos Firewall performance data explains these differences.

HA and recovery

High availability differs significantly depending on the platform.

When it comes to hardware, HA is usually easier to understand: two appliances, HA link, defined interfaces, clear replacement device. Additional questions arise for virtual and cloud deployments:

• Do HA nodes run on different hosts?
• Are storage, network and hypervisor really redundant?
• Are virtual MAC addresses and vSwitch rules compatible?
• Are there any dependencies on cloud routing or load balancing?
• Do backups and restores work on a new instance?
• Has the failure of a host or an availability zone been tested?

The basics of HA variants can be found in Sophos Firewall Setting up High Availability (HA). For recovery, Sophos Firewall Create or restore backup is required reading.

Licensing and Support

Licensing must be checked before deployment or resource changes. Older platform installation guidance limits both vCPU and vRAM to the purchased license; our internal licensing article describes a commercial virtual/software/cloud-BYOL change effective March 1, 2025 toward CPU-core licensing without the former RAM cap. That description is not proof that every SKU, legacy entitlement or Home license has identical conditions. Confirm the purchased SKU/core entitlement, serial number, subscription/support and the actual instance license status in the licensing portal before allocating resources; if the entitlement is unclear, stop and clarify it with the licensing provider. Do not apply the commercial change to Home licenses or infer unrestricted resources from this article. The 4 GB installation minimum and production RAM/storage/NIC sizing remain technical requirements, regardless of any applicable license ceiling.

For the Base License basics, see Sophos Firewall - Base License. The internal licensing-change context is described in Sophos Firewall VM & SW - Only CPU counts - No more RAM limit; confirm the actual entitlement rather than treating this blog as universal licensing proof.

What is important in operation:

• Document license and support status.
• Cleanly record serial number and registration status.
• Check HA licensing before building.
• Check firmware and support eligibility before upgrades.
• Know the RMA or recovery process for the chosen platform.

Before major upgrades, pre-upgrade checks for Sophos Firewall SFOS 22 should also be used because platform support, storage space, backup, HA and old VPN configurations can be upgrade-relevant.

For active-passive HA on virtual or software appliances, only the primary needs all required licenses, including the Base Firewall license. For active-active HA, each node needs its own Base Firewall license and the same additional protection licenses; their expiration dates may differ. Resolve this before building the cluster, not while diagnosing the first failover.

Decision matrix

• Classic location with WAN, LAN and DMZ: Mostly hardware. Virtual only with a good virtualization strategy.
• Data center with existing hypervisor team: Hardware is possible, virtual often makes sense.
• Cloud workloads in AWS or Azure: More virtual or cloud, not classic hardware.
• Easy support and RMA important: More hardware. With virtual or cloud, a lot depends on the platform team.
• Many physical ports required: More hardware. Virtual only with clean NIC and vSwitch design.
• Dynamic scaling and Infrastructure as Code: More virtual or cloud.
• Small IT team without specialized hypervisor knowledge: Mostly hardware; Plan virtual firewalls carefully.
• Tenant or segmentation design in the data center: Hardware is possible, virtual often makes sense.

Common errors

• Running a virtual firewall on an oversubscribed host.
• Failing to separate WAN, LAN and management cleanly on the hypervisor.
• Choosing hardware by price rather than capacity sizing.
• Deploying a cloud firewall without completing the routing design.
• Planning HA without testing host, storage or cloud failures.
• Creating backups without practicing restore.
• Checking license/support status only during an upgrade.
• Adding TLS Inspection or IPS without performance reserves.
• Involving platform, network and firewall owners only after an incident.

Checklist

• Location clearly defined: location, data center or cloud.
• Traffic, bandwidth and security features recorded for sizing.
• Hardware, virtual, software or cloud variants deliberately chosen.
• Responsibility for firewall, hypervisor, cloud and network documented.
• HA and recovery design checked.
• Backup and restore process tested or planned.
• License, support and registration clarified.
• Monitoring for firewall and underlying platform available.
• Upgradeability and platform support checked.
• Person responsible for platform, network, firewall, backup and restore named.

FAQ