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 native Azure HA. Suitable for small and controlled designs.
Load-balanced active-active	Two BYOL licenses or two PAYG instances	Cloud redundancy through Azure Load Balancer, not SFOS HA. Active-passive and VPN-tunnel management through this template aren’t supported.

For standalone, Sophos recommends at least Standard_F2s_v2 with two vCPUs and 4 GB RAM. Use a statically assigned Standard SKU public IP. The Basic SKU is retired and doesn’t belong in new deployments.

Deploy standalone from Marketplace

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 WAN subnet and PortB to the LAN subnet. Initially open NSGs only for required management sources.
Complete deployment and open WebAdmin at https://<public-ip>: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 the LAN subnet with Virtual appliance and that LAN address as next hop.
Test IP forwarding, NSGs, SFOS rules, and return path with a defined client.

The UDR forces outbound LAN traffic through the firewall. Without it, Azure sends packets along its default path. For a route-based connection to Azure VPN Gateway, also operate the XFRM interface with static routes, SD-WAN, or BGP.

Operate load-balanced active-active

The Sophos template creates two firewalls, one public, and one internal Azure Load Balancer. Its defaults use a /16 VNet and /24 WAN and LAN subnets; adapt the address spaces to the production architecture before deployment.

Azure health probes reach WebAdmin on 4444 and the proxy on 3128. Azure uses platform address 168.63.129.16 for this. Sophos adds matching SD-WAN routes through PortA. These runbook routes aren’t guaranteed to persist after a firmware upgrade, so rerun and verify the supplied Automation Runbook afterward.

By default, the first firewall uses 4444 and SSH 2222 for administration, while the second uses 4445 and 2223. Allow these ports only from fixed admin sources. The LAN UDR points 0.0.0.0/0 to the frontend address of the internal load balancer.

DNAT and return path

For inbound traffic, the public load balancer distributes the service to both firewalls. The matching SFOS DNAT rule then translates to the internal server. This Azure design uses MASQ so the reply returns through the same firewall and load balancer. Without a symmetric return path, connections work only intermittently or in one direction.

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.

Acceptance and operation

Acceptance covers both firewalls, load-balancer probes, backend pool, UDRs, NSGs, SFOS Rule IDs, DNAT, internet egress, and return path. After every firmware upgrade, verify the routes to 168.63.129.16, probe ports, and Automation Runbook. Azure snapshots aren’t a replacement for an exported SFOS backup; document rebuild, licensing, ownership, and cost alerts separately.