Connect Sophos Firewall to Azure VPN Gateway

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 with SFOS 22 and a current Azure VPN Gateway: 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 current designs. Current VpnGw*AZ SKUs are route-based; a true policy-based gateway is available only with the restricted Basic SKU and IKEv1. A route-based Azure gateway can use Use policy based traffic selectors to accommodate an on-premises policy-based firewall. This is a compatibility mode requiring selectors for every local/Azure prefix combination, not a policy-based Azure gateway. With Sophos SFOS 22, a route-based tunnel with an XFRM interface is clearer and is required for BGP, active-active and Azure NAT.

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 custom IPsec/IKE policies on VpnGw1 through VpnGw5 and VpnGw1AZ through VpnGw5AZ; Basic does not. Microsoft requires exactly one complete combination per connection. Use Microsoft’s custom IPsec/IKE policy reference as the authoritative check before changing a profile.

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.

Without a custom policy, at least one Sophos proposal must match the Azure default parameters. SFOS 22 IPsec profiles support DH groups 1, 2, 5, 14 through 21, and 25 through 31, but not DH group 24. A custom policy must therefore use only values in the intersection of both vendors’ current lists.

Azure fixes the IKE SA lifetime at 28,800 seconds; the route-based default policy uses 27,000 seconds and 102,400,000 KB for the quick-mode SA. A custom policy explicitly sets the quick-mode limits, while Microsoft allows local SA lifetimes to differ. SFOS still recommends a shorter key lifetime on the initiator and a phase 2 lifetime below phase 1 to avoid rekey collisions. Because Sophos initiates here, apply that ordering without inventing universal values and observe at least one rekey.

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. Apart from Basic with a minimum /29, current SKUs require at least /27; Microsoft recommends larger than /27 for future expansion.
4. No VMs or NSG are attached to GatewaySubnet. A 0.0.0.0/0 UDR is unsupported there, and BGP route propagation must remain enabled.
5. 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 and generation suitable for bandwidth, SLA, Availability Zone, BGP and NAT requirements
• Public IP for the gateway
• Active-active only if the local side can establish two tunnels to Azure’s two public IP addresses
• BGP only if ASN, peer IP and routing concept are defined

For new gateways, the VpnGw*AZ SKUs are the current path. VpnGw1AZ through VpnGw3AZ are available as Generation 1; Generation 2 starts at VpnGw2AZ and runs through VpnGw5AZ. Microsoft reserves VpnGw1 through VpnGw5 for migrations. Basic is not recommended for production workloads because of its feature and performance restrictions. Since bandwidth, tunnel counts and features change, check Microsoft’s current gateway SKU table during planning. Deployment often takes much longer than a firewall dialog.

In active-active mode, both IPsec tunnels belong to the same Azure connection, but each Azure gateway instance has its own public IP. Sophos therefore needs a separate route-based connection and XFRM interface for each Azure IP. The routing design must tolerate traffic over both tunnels and the loss of either path; establish, load and fail over each tunnel separately during acceptance.

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: all reachable local prefixes without BGP; with BGP the field can stay empty. Add static prefixes only when they are not learned through BGP.
4. Under Advanced, enable BGP and enter the Sophos ASN and BGP peer IP when using dynamic routing.

Azure normally uses a private address from GatewaySubnet as its BGP peer IP. If Sophos uses APIPA, assign Azure a unique address from 169.254.21.0 through 169.254.22.255; the local APIPA address can be from 169.254.0.1 through 169.254.255.254. Peer addresses must not overlap, and Sophos must initiate the BGP session when APIPA is used. Retrieve the final values under Virtual network gateway > Configuration; Microsoft’s portal BGP guide documents the details.

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. Understand and securely configure Sophos Firewall IPsec profiles explains how the Sophos fields work together and how to clone a custom profile cleanly. The specific values must still match the Azure default policy or the custom IPsec/IKE policy of the Connection exactly.

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.

For a clear route-based design, set both traffic selectors on Sophos to Any. The firewall then creates a numbered xfrm interface automatically. SFOS cannot create automatic firewall rules for Any-to-Any, so add the rules manually in the next step. NAT-T is always enabled on Sophos; behind upstream NAT, the IDs of both peers must also match exactly.

Configure route or BGP

Without BGP, use Download configuration on the Azure connection to obtain the generic device parameters, then assign the listed first tunnel IP, netmask and MSS to the XFRM interface under Network > Interfaces. Under Routing > Static routes > IPv4 unicast route, add each Azure prefix through that XFRM interface. Gateway can remain empty or use the peer address in the downloaded transfer subnet. With BGP, assign the on-premises BGP peer IP and netmask entered in the Local Network Gateway to XFRM instead; configure the Azure BGP peer IP shown under Virtual network gateway > Configuration as the Sophos neighbor. Do not invent transfer addresses.

With BGP, both sides must be planned carefully. Configure BGP on Sophos Firewall explains the base configuration, secure access and validation; for Azure, then use the peer values specified by Azure:

• 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.

The documented Azure BGP design uses IPv4. The local ASN must differ from Azure’s ASN and must not be one of Azure’s reserved ASNs: 8075, 8076, 12076, 65515, 65517, 65518, 65519, or 65520. Under Administration > Device access, allow Dynamic Routing from the VPN zone. Then verify that Sophos actually learns the Azure prefixes and that Azure shows the local prefixes under BGP peers.

For firewall-generated traffic, first verify the actual source address, advertised prefixes and return path. If the source is not in a local prefix routed by Azure, a targeted sys-traffic-nat mapping to the firewall’s LAN IP may be required; do not add it merely because BGP is enabled. Route system traffic selectively over IPsec provides the pre-check, Device Console syntax, validation and exact removal workflow.

Use NAT for overlapping networks only by design

If renumbering is impossible, Azure VPN Gateway can translate overlapping networks for S2S connections. Azure NAT is limited to VpnGw2 through VpnGw5 and VpnGw2AZ through VpnGw5AZ, route-based VPNs, and connections without policy-based traffic selectors. Static NAT maps 1:1 and allows initiation in both directions; dynamic NAT is stateful and can only be initiated from the Internal mapping side. With BGP, enable BGP route translation; Azure NAT does not support BGP APIPA addresses. Treat Microsoft’s NAT limits and mapping rules as design constraints, not an improvised fix.

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.

On Azure, VPN Gateway > Diagnostic settings with IKEDiagnosticLog, TunnelDiagnosticLog, RouteDiagnosticLog and GatewayDiagnosticLog gives stronger evidence than a reset. Compare Sophos and Azure timestamps for the same test. Reset the gateway only after these checks because a reset restarts the active gateway instance and can interrupt existing connections.

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. If several IPsec connections use the same endpoints, also check PSK selection: IKEv2 supports a unique PSK for each Local ID and Remote ID combination. IKEv1 supports only one PSK per local and remote gateway combination; SFOS applies the PSK from the most recently configured connection. Unique IDs with IKEv2 avoid this collision.

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.

Azure is initiator and the child SA expires

When Azure is the initiator, it rekeys an expiring child SA only while tunnel traffic exists. Without traffic, Azure deletes the child SA while phase 1 remains established. Later traffic from Azure can create a new child SA; traffic originating only behind Sophos Firewall can’t make Azure create it in this state. This is why Initiate the connection on Sophos is appropriate for this design. Azure’s IKE SA rekey can also cause a short interruption.

Roll back without destroying state

Before a change, export or record the Sophos connection, profile, XFRM address, routes and rules, plus the Azure gateway SKU/generation, connection, shared key, BGP and NAT settings. Do not delete the working connection. Clone the Sophos profile for a policy test and record the existing Azure policy under Connection > Configuration or with PowerShell.

If the change fails, reassign the previous Sophos profile and restore the exact former Azure custom policy, or remove only the newly added custom policy if Azure defaults were used before. Reactivate the existing connection and repeat tunnel, route and application tests. Do not pre-emptively delete the gateway, Local Network Gateway, XFRM interface, routes or NAT rules: that destroys the known state and can change public IPs or routing.

FAQ