Deploying Sophos Firewall into Microsoft Azure is a practical way to extend enterprise-grade network protection into your cloud estate, whether you need a single standalone perimeter VM, an active-passive HA pair behind an Azure Load Balancer, or an integrated Sophos Central-managed instance—this guide walks through the full process, explains key design decisions, surfaces common pitfalls, and highlights operational and security best practices for production rollouts.
Sophos provides a marketplace image and ARM templates to deploy Sophos Firewall as a virtual appliance in Microsoft Azure. The solution supports two licensing models—Pay-As-You-Go (PAYG) from the Azure Marketplace and Bring-Your-Own-License (BYOL)—and maps firewall VM sizes to Azure VM SKUs so you can match throughput and CPU requirements to your expected traffic load. The official Sophos documentation lists the minimum recommended VM as Standard F2s v2 (2 vCPU / 4 GB RAM) and explains the Marketplace deployment wizard, required network objects, and the post-deployment claim/registration flow in Sophos Central.
Sophos also maintains an ARM template and GitHub repository to automate deployments and to support more advanced architectures such as High Availability (HA) with manual load balancer configuration. Using templates reduces human error and speeds repeatable deployments across subscriptions and regions.
Microsoft Azure has important constraints and evolving platform behavior to account for—most notably the difference between Basic and Standard public IP SKUs and how they interact with availability zones, Azure Load Balancers, and the platform’s security defaults. Azure has announced the retirement of Basic SKU public IP addresses by September 30, 2025, which affects how new Sophos deployments should be planned and which public IP SKU to select for HA and availability. Review the Azure public IP guidance and upgrade options before finalizing architecture. (azure.microsoft.com, learn.microsoft.com)
Finally, Sophos’ cloud strategy increasingly pairs network controls with broader cloud resilience and data protection offerings; an integrated security posture—endpoint, network, identity, and backup—reduces reaction time during incidents. Administrators should consider how Sophos Firewall instances in Azure will be claimed in Sophos Central and mapped to existing security inventories and playbooks.
Notable strengths:
Source: YouTube
Background / Overview
Sophos provides a marketplace image and ARM templates to deploy Sophos Firewall as a virtual appliance in Microsoft Azure. The solution supports two licensing models—Pay-As-You-Go (PAYG) from the Azure Marketplace and Bring-Your-Own-License (BYOL)—and maps firewall VM sizes to Azure VM SKUs so you can match throughput and CPU requirements to your expected traffic load. The official Sophos documentation lists the minimum recommended VM as Standard F2s v2 (2 vCPU / 4 GB RAM) and explains the Marketplace deployment wizard, required network objects, and the post-deployment claim/registration flow in Sophos Central. Sophos also maintains an ARM template and GitHub repository to automate deployments and to support more advanced architectures such as High Availability (HA) with manual load balancer configuration. Using templates reduces human error and speeds repeatable deployments across subscriptions and regions.
Microsoft Azure has important constraints and evolving platform behavior to account for—most notably the difference between Basic and Standard public IP SKUs and how they interact with availability zones, Azure Load Balancers, and the platform’s security defaults. Azure has announced the retirement of Basic SKU public IP addresses by September 30, 2025, which affects how new Sophos deployments should be planned and which public IP SKU to select for HA and availability. Review the Azure public IP guidance and upgrade options before finalizing architecture. (azure.microsoft.com, learn.microsoft.com)
Finally, Sophos’ cloud strategy increasingly pairs network controls with broader cloud resilience and data protection offerings; an integrated security posture—endpoint, network, identity, and backup—reduces reaction time during incidents. Administrators should consider how Sophos Firewall instances in Azure will be claimed in Sophos Central and mapped to existing security inventories and playbooks.
Planning: prerequisites, topology choices, and licensing
Key prerequisites
- An Azure subscription with permissions to create Resource Groups, Virtual Networks (VNets), Public IPs, Network Interfaces, and Virtual Machines.
- A pre-created or planned Virtual Network with at least two subnets (commonly labelled WAN and LAN), or a design for a single-arm configuration when only one interface is required.
- A decision on licensing: PAYG (hourly via Marketplace) or BYOL (purchase from Sophos reseller). PAYG is convenient but limited to supported countries and the Marketplace billing model.
- An administrative password that meets Sophos’ complexity rules (minimum eight characters with mixed case, numbers and symbols when using template deployments).
Topology options
- Standalone single-instance deployment (simple perimeter). Use when resilience is not critical or for lab/testing environments.
- Active-passive HA pair behind an Azure Public Load Balancer (recommended for production). Load balancer health probes and floating IP configuration are required for failover. Sophos provides HA guidance for load-balancing in Azure. (docs.sophos.com, github.com)
- Single-arm deployments (one interface) for scenarios such as transparent inline inspection or when Azure routing makes dual-NIC placement unnecessary. Sophos documents single-arm deployment notes and caveats.
Public IP SKU consideration
- Historically, Sophos documented support for dynamic Basic SKU public IPs in Marketplace deployments for certain configurations. However, Azure’s platform changes make Standard SKU the forward-looking choice because Basic SKU creation will be restricted and retired; Standard SKU supports availability zones and integrates with Standard Load Balancer features essential for resilient HA. Plan to use Standard SKU public IPs for new deployments and validate any required NSG or routing adjustments. (docs.sophos.com, azure.microsoft.com)
Step-by-step deployment (Marketplace)
The following is a practical, production-minded walkthrough based on the Sophos Marketplace flow and Azure portal screens.- Prepare Azure resources
- Create or choose a Resource Group for the firewall and dependent resources. Place all related objects (VM, public IP, NICs, storage, route table) in the same resource group for easier lifecycle management.
- Build or select the Virtual Network and subnets
- Create a VNet with address space (for example, 10.0.0.0/16).
- Add a WAN subnet (e.g., 10.0.1.0/24) and a LAN subnet (e.g., 10.0.2.0/24).
- If you intend to route whole-subnet traffic through the firewall, plan to associate a Route Table that points default routes to the firewall’s LAN IP later.
- Create (or reserve) the Public IP address
- In the Azure portal, create a Public IP resource. Prefer Standard SKU with Static IP assignment for production HA compatibility. If following Sophos older guidance that references Basic dynamic skus, convert to Standard and static as appropriate given the Azure deprecation timeline. Keep a DNS label if you want a persistent hostname for accessing the firewall admin UI (the Sophos UI uses DNS name + port 4444). (docs.sophos.com, learn.microsoft.com)
- Launch the Sophos Firewall from Marketplace
- Search Marketplace for Sophos Firewall and click Create.
- Fill Basics: subscription, resource group, region, VM name, admin password (used for the
admin
account on the appliance). - Instance details: choose License type (PAYG or BYOL), select Virtual machine size (Default/Minimum: Standard F2s v2), select the Virtual network and the LAN/WAN subnets, and pick the public IP created in step 3. Review storage and other defaults.
- Validate and deploy
- Use the Marketplace validation and then Create. Deployment typically takes a few minutes. When complete, jump to the resource group and identify the NICs, VM, and public IP resource.
- Access the firewall admin console
- Copy the DNS name of the public IP and open
https://<dns-name>:4444
. Sign in with usernameadmin
and the password created in step 4. Accept the Sophos EULA. The console will prompt to claim the device in Sophos Central (recommended) or register with a serial number for BYOL. - Complete basic configuration and claim
- Use the setup wizard or skip it to configure interfaces, zones, NAT and rules manually.
- When claiming in Sophos Central, choose trial or final license and confirm module activations. Claiming centralizes logging and policy management.
High-availability (HA) and load-balancer patterns
Active-passive HA behind Azure Load Balancer
- Sophos supports HA in Azure by deploying two firewall VMs and placing them behind an Azure Load Balancer. The load balancer requires specific probe and NAT rule configuration to support floating IP and correct failover behavior. Sophos provides step-by-step instructions including health probes and manual load balancer configuration in its HA documentation. (docs.sophos.com, github.com)
- Key considerations:
- Use Standard Load Balancer paired with Standard SKU Public IPs for zone-aware failover.
- Configure health probes pointing at the Sophos HA monitoring endpoints.
- Ensure IP forwarding and proper NIC configuration to allow traffic to be accepted and responded to by the active node.
- Each firewall still needs a license (BYOL) or PAYG should be selected per instance in Marketplace. (docs.sophos.com, github.com)
Single-arm HA and limitations
Single-arm deployments are supported for certain use cases but have special considerations: there is no separate LAN interface and some Azure-native HA behaviors (like legacy active-active internal load balancer patterns) are not applicable. Sophos documents single-arm guidance and warns about interface configuration changes after factory reset.Optional: Route all VNet traffic through Sophos Firewall
If the firewall is intended to be the central internet egress and inspection point for VM workloads in the VNet:- Assign a static private IP to the firewall’s LAN NIC (so route table references are stable).
- Create an Azure Route Table, associate it with the target subnets, and add a route:
- Address prefix:
0.0.0.0/0
- Next hop type: Virtual appliance
- Next hop address: the firewall’s LAN private IP
- Associate the route table with the subnets you want to steer through the firewall.
- Verify connectivity and that NSGs allow required traffic. Sophos warns to power down the VM when certain NIC IP assignment changes are made to avoid transient routing issues.
Automation and templates
For repeatable, auditable deployments, use Sophos’ ARM templates (available on GitHub) or your own IaC tooling (ARM/ARM Bicep/Terraform). The Sophosxg-azure
repository includes a mainTemplate.json
, example parameter files, and an HA nested template for orchestrating multiple nodes and a load balancer. Review template parameter constraints and password rules before running to avoid failed deployments. Post-deployment validation and testing
- Confirm you can reach the Sophos admin UI on HTTPS port 4444 via the public DNS.
- Check interface IP addresses, routes, and NAT rules. Verify default gateway and ensure Azure NSGs and UDRs are not inadvertently blocking management traffic.
- If in HA, simulate failover and confirm the Azure Load Balancer redirects traffic cleanly to the standby node, and that session failover and stateful synchronization behave per your requirements. (docs.sophos.com, github.com)
- Test TLS/SSL inspection and any configured DPI functions with representative traffic and measure CPU utilization and latency on the chosen VM size.
Common pitfalls and troubleshooting
- Public IP SKU mismatch: selecting a Basic SKU public IP where a Standard SKU is required for Load Balancer or availability zone behavior will cause failures—plan Standard SKU for new production deployments given Azure’s migration roadmap. (azure.microsoft.com, learn.microsoft.com)
- NSG defaults: Standard SKU public IPs and Standard Load Balancers follow “secure by default” behaviors; ensure the correct NSG rules permit management and probe traffic.
- Azure DNS / firewall DNS name: Sophos uses the DNS name on the public IP for UI access. If you change or recreate the IP resource, the DNS name and assigned address may change—use static assignment where persistence is required.
- Licensing mismatch: BYOL requires registration with serial numbers; PAYG instances use Marketplace billing and are limited by regional availability. Confirm licensing model early in planning.
- HA complexity: Azure’s networking model for active-passive firewalls requires careful load balancer and probe tuning. Use Sophos HA guidance or the ARM HA template to reduce manual errors. (docs.sophos.com, github.com)
Security and operational best practices
- Claim each firewall in Sophos Central to unify logs, policies, and update management—centralized monitoring shortens detection-to-response times during incidents.
- Enforce MFA and strong role separation for Sophos Central admin accounts and Azure subscription-level admin roles.
- Harden NSG rules to allow only required ports (management port 4444, admin SSH if needed, but ideally restricted by IP ranges).
- Schedule periodic restore/recovery drills if Sophos Firewall integrates with broader incident response automations; the Sophos ecosystem increasingly ties into backup and recovery workflows for cloud resilience—consider how network-level recovery steps fit into your incident playbook.
- Monitor VM and throughput metrics; if the firewall CPU and throughput limits are approached, scale the VM to the next performance tier or design an HA pair with load distribution.
Cost, sizing, and performance guidance
- Minimum recommended instance: Standard F2s v2 (2 vCPU, 4 GB RAM). For production edge deployments with heavy TLS inspection, larger instance types will be required. Review Sophos PAYG pricing and Azure VM cost implications.
- Public IP and Load Balancer costs: Standard IPs and Standard Load Balancer resources incur additional charges—include these in your 1- and 3-year TCO models. Azure pricing pages and the Sophos PAYG pricing pages provide the necessary inputs for planning. (azure-int.microsoft.com, docs.sophos.com)
- Licensing trade-offs: PAYG simplifies trial and short-term use but may cost more in steady-state; BYOL is often more economical for long-term, predictable usage but requires separate license purchases and tracking. Align license type to procurement windows and expected lifetime of the deployment.
When to choose an automated template or Marketplace deployment
- Use Marketplace if you want a quick, interactive deployment and PAYG licensing, or for one-off lab/proof-of-concept setups.
- Use ARM templates / IaC when you need repeatable, parameterized deployments for multiple subscriptions, automated CI/CD infrastructure pipelines, or to integrate Sophos Firewall deployment with other infrastructure automation (e.g., routing, NSGs, and load balancer rules). Sophos’ GitHub examples are a good starting point. (github.com, techvids.sophos.com)
Final checklist before production cutover
- Confirm public IP SKU and availability zone alignment (prefer Standard SKU).
- Validate NSG rules for management, health probes, and expected traffic flows.
- Ensure all firewall instances are claimed in Sophos Central (or registered with the correct serials for BYOL).
- Test routing and failover flows end-to-end, including stateful failover for active sessions. (docs.sophos.com, github.com)
- Review monitoring and alerting (logs forwarded to SIEM/XDR) and confirm backup/restore plans for configuration state.
Conclusion — strengths, limitations, and recommended approach
Deploying Sophos Firewall in Azure provides a straightforward path to run a full-featured next-generation firewall in a cloud-native way, with centralized management via Sophos Central and multiple deployment patterns—from single-instance perimeter VMs to HA pairs behind Azure Load Balancer. The documented Marketplace wizard and ARM templates make initial provisioning routine, and Sophos’ documentation covers the key networking and registration steps administrators need for a successful deployment. (docs.sophos.com, github.com)Notable strengths:
- Rapid deployment via Marketplace and ARM templates; central management through Sophos Central simplifies lifecycle management. (techvids.sophos.com, github.com)
- Flexible licensing options (PAYG or BYOL) let you align procurement and billing to organizational needs.
- HA support with Azure Load Balancer gives a resilient architecture for production egress and inspection.
- Azure platform changes—notably public IP SKU retirement—require planning and may force rework if Basic SKUs are used; choose Standard SKU for new builds.
- Operational complexity for HA and routing scenarios; misconfigured load balancer probes, NSGs, or UDRs can lead to outages without careful testing. (docs.sophos.com, learn.microsoft.com)
- Sizing and cost: TLS inspection and deep DPI are CPU-intensive—under-sizing will result in latency and throughput constraints. Include realistic traffic profiles during sizing and testing.
- Start with a test deployment using the Marketplace image to validate functionality and policies.
- For production, automate deployment via ARM templates, use Standard SKU public IPs with static assignment, configure HA behind a Standard Load Balancer, and claim devices in Sophos Central.
- Run failover tests, measure performance under representative loads, and integrate monitoring and backup workflows into your broader security and DR plans. (github.com, docs.sophos.com)
Source: YouTube