← Blog

Sophos Firewall in Azure: HA with load balancers, and why Central beats “cluster sync” here

On-prem HA vs Azure: the mental model shift

On hardware or a classic datacenter, high availability for firewalls often means paired appliances: heartbeat links, floating or shared addressing, and state replication so failover feels like one logical unit. Configuration is synchronized between nodes by the HA mechanism itself.

In Microsoft Azure, you typically deploy two (or more) separate virtual machines, each with its own OS disk, own NICs, and own lifecycle. Azure does not give you a shared L2 segment that behaves like two firewalls holding hands on the same wire. Instead, Azure Load Balancer (or Azure Gateway Load Balancer in some designs) sits in front of—or beside—your design and steers traffic based on health probes and rules.

Result: your “HA pair” in Azure is often two independent Sophos Firewall instances that share responsibility for traffic via Azure networking, not a single Sophos HA cluster in the traditional on-prem sense. Failover is orchestrated by Azure path selection and your routing design, plus healthy backends—not by a proprietary cluster link between the VMs.

What Azure Load Balancer is doing

For inbound flows you commonly:

  • Place an Azure Load Balancer (public or internal) in front of the NICs that should receive traffic.
  • Define backend pools containing the private IPs of each Sophos VM (or the relevant front-end interface, depending on topology).
  • Configure health probes (TCP/HTTP/HTTPS) that match what Sophos actually answers on the probed port—if the probe fails, Azure stops sending new flows to that node.

For egress and symmetric flows, you also need a coherent plan for SNAT, user-defined routes, and NVAs (network virtual appliances). Sophos publishes reference architectures for Azure—use them as the baseline rather than inventing topology from memory.

Why configuration does not “just sync” like on-prem HA

Because the firewalls are not in a classic Sophos HA pair in the same way as two appliances in one rack, you should not assume:

  • automatic object-level sync,
  • session sync for every feature, or
  • identical failover behaviour without testing.

You must treat each VM as a first-class firewall with its own runtime state, then deliberately align policy between them.

Sophos Central and “management parity”

This is where Sophos Central and central firewall management come in—what you may see documented as Firewall Management with group-style or template-style workflows (including concepts referred to under Group Policy Management in the Central experience for keeping appliances aligned).

Use Central to:

  • Apply consistent rulebases, objects, and policies to both Azure firewalls where your subscription allows it.
  • Reduce configuration drift when an admin changes one node and forgets the other.
  • Audit changes and maintain change discipline appropriate to two live edges.

It is still not magic: you are replicating intent through management tooling, not relying on a single cluster brain. Validate that every NAT, VPN, and dynamic object behaves the same on both units after a change. Some features may still need manual parity checks per Sophos guidance for multi-site or standalone peers.

A practical workflow

  1. Design Azure networking first: VNet, subnets, UDRs, load balancer SKU, probe endpoints.
  2. Deploy two Sophos SFOS VMs from the supported Azure image path, each licensed and registered to Central as appropriate.
  3. Attach them to backend pools and prove probe health independently (take one VM offline and watch traffic shift).
  4. Build policy in Central (or build once and assign to both) so firewall rules, IPS profiles, and common objects stay aligned.
  5. Test failover at application level: DNS TTLs, SNAT stickiness, VPN tunnels, and asymmetric routing are where Azure + firewall combos usually bite.

Summary

  • Azure HA for Sophos is not the same as traditional appliance HA—think load-balanced independent nodes.
  • Azure Load Balancer + probes decide who is live for new flows; you must design routing and NAT correctly.
  • Use Sophos Central (Firewall Management / group or template workflows—including approaches described as Group Policy Management for aligned policy) to duplicate and maintain configuration across firewalls instead of assuming built-in HA sync.

Always confirm feature support, licensing, and Azure reference designs in current Sophos documentation—cloud UI names and capabilities change faster than blog paragraphs.