Skip to content
Avanet

Connect Sophos Firewall to Azure VPN Gateway

Sophos Firewall

An Azure VPN Gateway connects an on-premises network to an Azure Virtual Network over Site-to-Site IPsec. On Sophos Firewall, this is usually built as a route-based IPsec VPN. Larger or more dynamic environments often add BGP.

This article explains the practical flow between Sophos Firewall and Microsoft Azure: which Azure objects are required, how the Sophos side is built, which IPsec/IKE parameters must be matched deliberately and how to verify after saving that traffic really flows. For general IPsec basics, start with setting up Sophos Firewall Site-to-Site IPsec VPN. If an existing tunnel is green but carries no traffic, use Sophos Firewall IPsec VPN Troubleshooting.

When this article fits

This article fits when a local network behind a Sophos Firewall should be connected to an Azure Virtual Network. It covers a Site-to-Site tunnel between Azure VPN Gateway and the local firewall, not Point-to-Site VPN for individual users and not Sophos Firewall as a virtual appliance in Azure.

Typical scenarios:

  • local server network to Azure VMs
  • branch or main site to Azure Virtual Network
  • hybrid scenario with AD, DNS, backup, monitoring or management in Azure
  • migration from policy-based designs to route-based IPsec
  • optional BGP for dynamic routing between local network and Azure

Azure and Sophos do not always use the same terms. In Azure, the relevant objects are Virtual network, Gateway subnet, Virtual network gateway, Local network gateway and Connection. On Sophos Firewall, the relevant parts are the IPsec connection, XFRM interface, routes, firewall rules and optionally BGP.

Plan before configuration

An Azure tunnel should not be treated as a pure click wizard. Most issues come from overlapping networks, wrong gateway SKUs, mismatched IPsec/IKE parameters, missing routes or firewall rules without logging.

Networks and address spaces

Local networks and Azure address spaces must not overlap. Azure routes the local prefixes entered in the Local network gateway to the Sophos Firewall. The Sophos Firewall routes Azure prefixes over the XFRM interface or through BGP.

Document beforehand:

  • Azure Virtual Network Address Space, for example 10.50.0.0/16
  • Azure subnets, especially workload subnets
  • local network behind Sophos Firewall, for example 172.16.10.0/24
  • public IP of the Sophos Firewall or upstream router
  • Azure public IP of the Virtual Network Gateway
  • BGP yes or no
  • shared pre-shared key
  • planned test systems on both sides

If local and Azure networks overlap, fix the design first. NAT over IPsec is possible, but it makes operations and troubleshooting significantly harder.

Route-based instead of policy-based

For Azure, route-based IPsec is the right choice for most current designs. Azure VPN Gateway is typically operated as route-based, especially when multiple prefixes, BGP, active-active or later extensions are planned.

On Sophos Firewall this means:

  • Plan the IPsec connection as a route-based tunnel interface.
  • Check the XFRM interface after saving.
  • Set routes or BGP for Azure prefixes.
  • Create firewall rules between local zones and the VPN zone.
  • Verify traffic with Log Viewer and Azure connection status.

A green tunnel status is only part of acceptance. The tunnel is really verified only when a defined client reaches a defined Azure destination and both sides show logs or counters.

Do not guess IPsec/IKE parameters

Azure VPN Gateway supports defined IPsec/IKE parameters and, with suitable gateway SKUs, custom IPsec/IKE policies. Microsoft notes that a custom policy must be specified completely; partial policies are not enough.

For operations this means:

  • Choose the IKE version deliberately, usually IKEv2.
  • Document encryption, integrity, DH group, PFS and lifetimes.
  • Mirror Azure Custom Policy and Sophos IPsec Profile.
  • Do not blindly transfer Sophos-to-Sophos defaults to Azure.
  • Plan a maintenance window and rollback point after every policy change.

If no Custom Policy is set, the Sophos profile must match the Azure defaults. If a Custom Policy is set, all values must be maintained cleanly on both sides.

Prepare the Azure side

The Azure configuration consists of several objects. Names should be clear because troubleshooting later becomes messy quickly.

Virtual Network and Gateway subnet

The Azure Virtual Network needs a dedicated GatewaySubnet. This subnet is used by Azure VPN Gateway and must not be used for normal VMs.

Check:

  1. Azure Virtual Network exists.
  2. Address Space does not overlap with local networks.
  3. GatewaySubnet exists and is sized sufficiently.
  4. Workload subnets and Network Security Groups allow the desired traffic.

Create Virtual Network Gateway

The Virtual network gateway is the actual Azure VPN Gateway. These points matter:

  • Gateway type: VPN
  • VPN type: Route-based
  • SKU suitable for bandwidth, SLA, Availability Zone and BGP requirement
  • Public IP for the gateway
  • Active-active only if the local side is designed for it
  • BGP only if ASN, peer IP and routing concept are defined

Gateway deployment in Azure often takes much longer than a normal firewall dialog. Plan that time.

Create Local Network Gateway

The Local network gateway describes the local side from Azure’s perspective.

Enter:

  1. Name, for example lng-sophos-hq.
  2. Endpoint as public IP address or FQDN of the Sophos side.
  3. Local Address spaces if working without BGP.
  4. BGP settings if dynamic routing is used.

If the Sophos Firewall is behind NAT, check carefully which public IP Azure sees and how NAT-T, port forwarding and IDs are implemented locally. The simple standard path is a Sophos Firewall with its own public IP.

Create Connection

The Connection links Virtual Network Gateway and Local Network Gateway.

Important values:

  • Connection type: Site-to-site (IPsec)
  • Shared key: identical to the Sophos pre-shared key
  • IKE Protocol: matching the Sophos configuration
  • BGP: enable only if both sides use BGP
  • Custom IPsec/IKE policy: set only if the values were planned deliberately

After creating the Connection, the Azure side is ready, but not automatically productive. The Sophos side must know the same tunnel, the same parameters and the return path.

Configure Sophos Firewall

On Sophos Firewall, the tunnel is created under Site-to-site VPN > IPsec.

Prepare IPsec profile

Under Profiles > IPsec profiles, use or create a profile that matches Azure. The values must match the Azure default policy or the custom IPsec/IKE policy of the Connection.

Document:

  • IKE version
  • Phase 1 encryption and authentication
  • DH group
  • Phase 2 encryption and authentication
  • PFS
  • Key lifetime

If Azure uses a Custom Policy, reflect this in the profile name, for example Azure_IKEv2_AES256_G14.

Create route-based IPsec connection

Menu path:

Site-to-site VPN > IPsec

Procedure:

  1. Open Add.
  2. Select Route-based or tunnel interface as connection type.
  3. Set a name, for example azure-vnet-prod.
  4. Set Gateway type on the Sophos side usually to Initiate the connection.
  5. Enter the Azure public IP of the Virtual Network Gateway as Remote Gateway.
  6. Set the pre-shared key identical to the Azure Connection.
  7. Check Local ID and Remote ID, especially with NAT or multiple tunnels.
  8. Select IPsec profile.
  9. Save and activate the connection.

After saving, check the XFRM interface under Network > Interfaces. It remains assigned to the VPN zone. Depending on the design, it is used with a static route, SD-WAN route or BGP.

Configure route or BGP

Without BGP, Sophos Firewall needs a route to the Azure prefixes. Usually this is a static route or SD-WAN route over the XFRM interface.

With BGP, both sides must be planned cleanly:

  • local ASN of Sophos Firewall
  • Azure ASN
  • BGP peer IPs
  • allowed and advertised prefixes
  • route advertisement in Azure
  • firewall rules for actual user traffic

BGP does not replace firewall rules. It only distributes routes. Whether a server in Azure is reachable is still decided by routing, NSG, firewall rules and the destination system.

Create firewall rules

Traffic through the tunnel needs matching rules, usually between the internal zone and the VPN zone.

Recommended during rollout:

  • Use concrete networks or hosts as source and destination.
  • Choose services deliberately for the first test, for example ICMP, RDP, HTTPS or DNS.
  • Enable Log firewall traffic.
  • Do not leave rules on Any after the first test.
  • Check the opposite direction separately if Azure must also reach local systems.

If the rule does not match, use Sophos Firewall rule not matching: check causes.

Verify the connection

Acceptance should always check two layers: tunnel status and real traffic.

Check Azure

In Azure:

  1. Open the Connection of the VPN Gateway.
  2. Check connection status.
  3. Watch data counters.
  4. Check effective routes of the affected Azure VM.
  5. Check Network Security Group of the target subnets.

Azure status alone is not enough. A VM may be unreachable despite an established Connection because of NSG, local Windows firewall, wrong route or missing return path.

Check Sophos Firewall

On Sophos Firewall:

  1. Check Site-to-site VPN > IPsec status.
  2. Check the XFRM interface under Network > Interfaces.
  3. Check the route to Azure prefixes.
  4. Filter Log Viewer for test traffic.
  5. Use Packet Capture or strongswan.log if needed.

For IPsec logs and CLI analysis, use Sophos Firewall IPsec VPN Troubleshooting.

Use realistic test traffic

ICMP is a good start, but not a complete test. Then test the service that will be used in production:

  • DNS to an Azure DNS server or domain controller
  • RDP or SSH to a test VM
  • HTTPS to an internal application
  • backup, monitoring or management traffic

The source matters. A ping directly from the firewall does not prove the same thing as a test from a client behind the firewall.

Typical errors

Tunnel stays down

Usually gateway IP, IKE version, pre-shared key, IDs or IPsec/IKE parameters do not match. On Sophos Firewall, check strongswan.log first and compare Azure Connection settings with the Sophos IPsec profile.

Tunnel is connected, but no traffic flows

Routes, firewall rules, Azure NSG rules or return path are often missing. On the Sophos side, check Log Viewer and routes. On the Azure side, check Effective Routes and NSG.

Only one direction works

This often points to asymmetric routing, NSG, host firewall or missing reverse rule. Test both directions separately and document the source of the test traffic.

BGP learns no routes

Check ASN, peer IP, BGP enablement, XFRM address and Azure BGP configuration. Then verify which prefixes are actually advertised and learned. An established IPsec tunnel does not automatically mean BGP routes correctly.

Tunnel fails after policy change

Custom IPsec/IKE policies must be complete and compatible. If Azure and Sophos interpret only one value differently, the connection may fail. Before changes, document the current profile, Azure policy and known working state.

FAQ

Should Sophos Firewall connect to Azure policy-based or route-based?

For Azure, route-based IPsec is usually the better choice, especially with multiple networks, BGP or later extensions. Policy-based designs are usually less flexible for Azure.

Does Azure VPN Gateway require BGP?

No. For simple connections, static routes or Address Spaces in the Local Network Gateway are enough. BGP is useful when prefixes should be learned dynamically or multiple paths are planned.

Why is the Azure tunnel green, but the VM is unreachable?

IPsec is probably established, but routing, firewall rule, Azure NSG, local Windows firewall or return path does not match. Tunnel status and real application traffic must therefore be tested separately.

Can the Sophos Firewall be behind NAT?

It can work, but it is not the simple standard case. Public IP, NAT-T, port forwarding, Local ID, Remote ID and Azure Local Network Gateway must then be planned and tested especially carefully.

Do Azure IPsec parameters need to be set explicitly?

Not always. If no Custom IPsec/IKE Policy is used, the Sophos profile must match the Azure defaults. If a Custom Policy is used, all parameters must be set completely and compatibly on both sides.