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

Model	License	Important boundary
Standalone	BYOL or PAYG	One appliance without redundancy, for controlled workloads with an accepted maintenance window.
Load-balanced active-active	One BYOL license per firewall or PAYG	Two independent firewalls behind Standard Load Balancers with HA Ports; the template doesn’t support active-passive.

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. Sophos explicitly supports only zone 1 for this procedure. 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

Select Sophos Firewall in Azure Marketplace and choose BYOL or PAYG.
Define the resource group, region, and instance size. VNet and subnet ranges must not overlap each other or remote networks.
Map PortA to the LAN subnet and PortB to the WAN subnet. Initially open NSGs only for required management sources.
Complete deployment and open WebAdmin at https://<dns-name>:4444.
Complete the setup assistant, registration, licensing, and firmware process in a controlled manner.
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.
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.

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

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.
From that VM, test DNS, HTTPS egress, and the required application. In Log viewer > Firewall, confirm the expected Rule ID, source, and destination.
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.
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.