Deploy and route Sophos Firewall on Azure

Sophos Firewall can be deployed from Azure Marketplace as one appliance or through a load-balancer template with two firewalls. Sophos calls the second design active-active, but it isn’t a native SFOS HA cluster. Configuration, sessions, and status aren’t synchronized as they are between two HA appliances.

⚠️ Azure routing is part of the firewall configuration. A correct SFOS rule isn’t enough when a User Defined Route, Network Security Group, or load-balancer return path is missing. Validate every release as a complete forward and return path.

Select operating model and license

Azure VM/infrastructure charges are separate from Sophos software charges. PAYG is hourly, with no minimum commitment in the documented model, and includes the Xstream protection bundle. Individual software subscriptions and Enhanced Plus Support cannot be added to PAYG. Availability is limited to Microsoft remittance countries; confirm the subscription’s billing country and offer before purchase, and use BYOL if PAYG is unavailable. BYOL is purchased through an authorized reseller and allows a choice of bundles, individual subscriptions such as Network Protection, Web Protection and Zero-Day Protection, and support including Enhanced Plus Support. The documented BYOL terms are one, two or three years; confirm the actual offer and entitlements rather than assuming a price or support promise. Stopping software usage does not automatically remove chargeable Azure resources.

Sophos specifies Standard_F2s_v2 with two vCPUs, 4 GB RAM, and at least two NICs as the minimum. Actual sizing must also account for throughput, enabled protection features, and Azure quotas.

For a new standalone deployment, pre-create the Standard SKU public IP under Public IP addresses > Create with IP version: IPv4, SKU: Standard, Availability zone: 1, Tier: Regional, IP address assignment: Static, and Routing preference: Microsoft network. Set a unique DNS name label and select Domain name label scope: None. Sophos also specifies DDoS protection > Protection type: Network for this procedure. That option requires a suitable Azure DDoS plan and can add cost, so confirm the plan with the Azure owner before creating the address. Then select it in the Sophos form under Public IP name. Availability zone: 1 is the documented example selection. Separately, the firewall has a single-availability-zone limitation; this does not establish that only zone 1 is supported, or validate another zone or a multi-zone design. The former dynamic Basic SKU option is no longer a basis for a new deployment after Azure retired that SKU.

Deploy standalone from Marketplace

Create and secure the appliance

1. Select Sophos Firewall > Create in Azure Marketplace and choose BYOL or PAYG. Under Basics, enter the subscription, resource group, region, VM name, and a strong initial admin password.
2. Define the approved instance size, VNet, LAN and WAN subnets, the pre-created Standard SKU IP under Public IP name, and a storage account. VNet and subnet ranges must not overlap each other or remote networks.
3. Map PortA to the LAN subnet and PortB to the WAN subnet. Initially open NSGs only for required management sources.
4. Complete deployment and open WebAdmin at https://<dns-name>:4444.
5. Sign in with admin and the deployment password, accept the terms, then complete the setup assistant, registration, licensing, and firmware process in a controlled manner.
6. Set the LAN NIC’s private address to Static in Azure. Then add a 0.0.0.0/0 UDR to each workload subnet with Virtual appliance and that LAN address as next hop.
7. Test IP forwarding, NSGs, SFOS rules, and return path with a defined client.

Prepare the address plan

Use, for example, VNet 10.20.0.0/16, LAN 10.20.10.0/24 on PortA, WAN 10.20.20.0/24 on PortB, and 10.20.10.4 as the static LAN IP. These RFC 1918 values are placeholders. Replace them with unused ranges that don’t overlap peered, VPN, or on-premises networks.

Create the LAN UDR with exact Azure fields

Sophos requires the VM to be stopped before changing the LAN private IP to static. Use Virtual machines > > Stop, then open the LAN NIC and Settings > IP configurations > ipconfig, retain the planned address, and set Allocation: Static. Start the VM again afterward.

Create the route table under Route tables > Create. Under Subnets > Associate, select every client or workload subnet whose traffic must traverse the appliance. If clients are directly in PortA’s LAN subnet, associate that LAN subnet, as in Sophos’ basic example. Don’t associate the firewall’s WAN subnet. Under Routes > Add, use Route name: default-via-sfos, Destination type: IP Addresses, Destination IP addresses/CIDR ranges: 0.0.0.0/0, Next hop type: Virtual appliance, and Next hop address: 10.20.10.4. Check Enable IP forwarding on both firewall NICs; Azure requires it when a NIC forwards packets not addressed to itself.

The UDR forces outbound traffic from the associated workload subnet through the firewall, while more specific Azure routes still win. Decide whether Propagate gateway routes fits the VPN or ExpressRoute design rather than copying Yes blindly. For a route-based connection to Azure VPN Gateway, propagated and custom routes must also match the XFRM, SD-WAN, or BGP design. Add a tightly scoped, logged LAN-to-WAN rule under Rules and policies > Firewall rules.

Operate load-balanced active-active

The Sophos template creates two firewalls and an external and internal Standard Load Balancer with HA Ports. It requires a /16 VNet and /24 LAN and WAN subnets. Don’t alter these prefix sizes independently: Sophos instructs customers to contact their Sophos representative before using different subnet sizes.

Azure health probes reach WebAdmin on 4444 and the proxy on 3128. Internal probing also depends on special routes to platform address 168.63.129.16 that the Automation Runbook injects into the kernel routing table. These routes don’t persist across firmware upgrades, so rerun and verify the supplied runbook afterward.

During deployment, Trusted network must initially be * because the Azure Automation Runbook connects from public Azure addresses. Restrict the NSG to documented admin CIDRs immediately after the runbook succeeds. By default, the first firewall uses WebAdmin 4444 and SSH 2222, while the second uses 4445 and 2223. Register both appliances separately and maintain identical firewall, NAT, and routing configuration on both.

Configure probes and egress

On both firewalls, configure the internal and external load-balancer gateways under Routing > Gateways and the documented probe routes under Routing > SD-WAN routes. The external probe route must rank above the internal route. For workload egress, the 0.0.0.0/0 Azure route uses Next hop type: Virtual appliance and the internal load balancer frontend IP—not either firewall NIC—as Next hop address. Both firewalls also need the same logged LAN-to-WAN rule.

The load balancers probe TCP 4444 and 3128. If you change them, internal and external probes must use different ports. In the NSG, allow the probe path with source service tag AzureLoadBalancer; inside the appliance the source appears as 168.63.129.16. SFOS listeners and the Sophos-documented special routes must match as well. Treat neither the service tag nor the platform address as a generally trusted internet source. Verify both backends under Load balancer > Monitoring > Insights or the Health Probe Status metric. A healthy probe confirms only that its port responds, not that the application and return path work.

Start the template deployment deliberately

Open the active-active deployment resource, review and record the template revision, then use Deploy to Azure. This is a deployment resource, not a substitute for the following runbook. Before Next > Create, check:

• Subscription, Resource group, Region and Location; verify that the intended region supports Automation accounts in this subscription before deploying.
• Base URL: retain the reviewed template value. VM name, a securely stored Admin password, Image SKU (BYOL or PAYG-new) and VM size with at least two NICs.
• Net new or existing, Net RG, Net name, Net prefix (/16); WAN name/prefix and LAN name/prefix (/24). Loadbalancer Int IP must be a free address in the LAN prefix.
• The new/existing choices, groups and names for Public IP, Storage, Network security group, Availability set and Automation account; also Public IP DNS, Storage type, NIC WAN, NIC LAN, and Number of instances: 2. Check existing resources and the unique DNS label before submission.
• Record the original NSG rules and the approved time limit for the template’s initial Trusted network: * exposure. Restore restricted management access even if automation fails. If the exception cannot be approved, stop rather than deploying with indefinite public management access.

After deployment, inventory both NIC/subnet mappings, subnet gateways, load-balancer frontends, probes and management-port mappings. These actual values—not the standalone example above—are the inputs below.

Map the gateways and probe routes on both appliances

Under Routing > Gateways > Add, create distinct internal/external gateways and save each:

The retained example uses 10.54.11.1 and 10.54.22.1 and selects WAN for both gateways, although it later binds the internal route to #PortA and the external route to #PortB. This unusual mapping is deployment-specific, not a universal LAN/WAN prescription. Check the deployed NICs, SFOS interfaces and subnet reachability first. If the selected interface cannot reach the intended subnet gateway, stop and resolve the mapping with the deployment owner; do not blindly copy the example or invent a replacement.

Under Routing > SD-WAN routes > Add, create the internal route first, then the external route, both at Top:

Confirm the actual interface objects and service definition against the probe flow. The external recipe’s HTTP selection does not mean changing TCP probes 4444/3128 to port 80. Do not generalize an unspecified internal service to a broad production route: the destination and source remain narrowly bound. Save, keep the external route above the internal route, and repeat the checked mapping on the second appliance. Check Load balancers > Monitoring > Metrics > Health probe status, aggregation Avg, filtered by Backend IP address, for each backend and both load balancers; then test actual egress and return traffic.

Recover injected routes after firmware changes

Schedule a maintenance window: the documented runbook restarts the firewall VM and can drop sessions. Export SFOS backups, save the deployed runbook and NSG rules, and confirm a healthy remaining backend before working on one VM. If both backends are unhealthy, plan an outage; do not promise uninterrupted recovery.

1. In Azure, open Network security groups > [firewall NSG] > Inbound security rules > allow_ssh. Identify the actual runner’s permitted access to the mapped SSH port. The retained recovery sets Source: IP address, Source IP addresses/CIDR ranges: 0.0.0.0/0. This is a high-risk, temporary source exception, not a permanent recommendation. Prefer a verified narrower runner path; if none is established, require explicit approval, a short time limit and restriction to the required SSH mapping. Never guess an Azure source CIDR or broaden unrelated ports.
2. Open the deployment resource group, locate the Automation account > Runbooks > [deployed runbook], then Edit > Edit in portal. The retained revision says to comment lines 20–24. Identify the intended block in the actual script and preserve its original first; line numbers are not a safe edit instruction for another revision. If its purpose is unclear, stop. Save > Publish, review the diff, then Start.
3. Enter the following values for the first VM, not for the other backend:

4. Start the job and inspect its output/errors and status. Completed is only job completion: wait for the VM restart and management access, verify the injected 168.63.129.16 route, both probe paths and a real application/egress test. Only then recover the second VM with its own parameters.
5. Restore the recorded NSG source restrictions immediately, including on failure, and verify effective access. On failure, leave the healthy backend serving traffic, retain job/error evidence, restore the saved script if the edit was wrong, and escalate before rerunning or touching the other backend. Never infer 100% health or restored internet from Completed alone.

DNAT and return path

For inbound traffic, the external load balancer selects a firewall. HA Ports carry NVA flows across protocols and ports, but don’t replace a service-specific publication. Create a matching health probe and load-balancing rule for the published TCP service on the external load balancer, and bind the rule to that probe. The SFOS NAT rule then translates to the internal server. In Rules and policies > NAT rules, set Translated source (SNAT): MASQ so the server replies to the LAN IP of that same firewall. Without MASQ, the reply can traverse the internal load balancer and the other firewall, breaking the session through asymmetric routing.

Direct RDP from the internet isn’t a recommendation. Prefer VPN or ZTNA. If a service must be published, tightly restrict source, service, and destination in Azure and SFOS, enable logging and IPS, and perform a negative test from an unauthorized network.

Validate, troubleshoot, and roll back

Acceptance checks

1. Check Effective routes on a test VM. 0.0.0.0/0 must show the expected firewall LAN IP, or the internal load balancer IP for active-active, as next hop.
2. From that VM, test DNS, HTTPS egress, and the required application. In Log viewer > Firewall, confirm the expected Rule ID, source, and destination.
3. For a published service, perform a positive test from an allowed network and a negative test from a disallowed one. Verify the DNAT target and server return path separately.
4. For active-active, check Health Probe Status and the backend pool. Only in a maintenance window, remove one firewall, test new connections through the remaining instance, and restore a healthy backend before testing the other. Existing sessions aren’t synchronized and can drop during this test.

Typical faults

• No egress after associating the route table: Check Effective Routes, workload-subnet association, static LAN IP, IP forwarding, NSG, and SFOS Rule ID in that order.
• Probe unhealthy: Check TCP protocol and port, listener, NSG, and SD-WAN routes for 168.63.129.16. Opening the service broadly to the internet doesn’t fix a probe.
• Probe fails after an SFOS upgrade: Routes injected by the Automation Runbook aren’t persistent. Rerun the Sophos-supplied runbook for both VMs, verify probe health, and immediately return any temporarily broadened SSH NSG to the allowed admin CIDRs.
• DNAT works intermittently: Compare the NAT and firewall rules on both appliances, Translated source (SNAT): MASQ, load-balancer backend, and the server’s return route.

Before an egress rollback, record the previously approved next hop. Reassociate the prior route table, or isolate the workload subnet while changing routes. Simply disassociating the new route table can activate Azure’s 0.0.0.0/0 -> Internet system route and bypass the firewall; do that only when this path has been explicitly reviewed and accepted. Remove the UDR or temporary rules only after the restored return path is validated. For DNAT, disable or remove the external load-balancer rule before dismantling the Azure and SFOS rules. Azure snapshots don’t replace an exported SFOS backup; document rebuild, licensing, ownership, and cost alerts separately.

For the next integration step, use the internal Azure VPN Gateway runbook or the Entra Domain Services setup in the AD runbook.