Connect Sophos Firewall to AWS Site-to-Site VPN

An AWS Site-to-Site VPN connects a local network behind Sophos Firewall to an AWS VPC or a Transit Gateway. Technically it is an IPsec VPN, but operationally it differs from a normal Sophos-to-Sophos tunnel: AWS creates two tunnels per VPN connection, uses customer gateway and target gateway objects, and routing depends heavily on whether static routes or BGP are used.

This article explains the practical setup with Sophos Firewall and AWS. It complements the general guide Set up Sophos Firewall Site-to-Site IPsec VPN with AWS-specific pitfalls: two tunnels, BGP neighbours, route tables, security groups, NACLs and status checks in AWS and Sophos. If a tunnel is already up but traffic does not pass, Sophos Firewall IPsec VPN troubleshooting is the better next step.

When this article fits

This article fits when a site, data centre or local network must be connected to AWS through Sophos Firewall. It covers AWS Site-to-Site VPN to a VPC, Virtual Private Gateway or Transit Gateway. It does not cover Sophos Firewall as a virtual appliance running inside AWS.

Typical scenarios:

• local server network to EC2 instances in a VPC
• backup, monitoring or management traffic to AWS
• hybrid DNS, AD, jump hosts or administration networks
• migration from static VPN to dynamic BGP routing
• redundant tunnel operation with two AWS tunnels

AWS and Sophos use different terms. In AWS, the relevant objects are Customer Gateway, Virtual Private Gateway or Transit Gateway, Site-to-Site VPN connection, Tunnel Details, Route Tables, Security Groups and Network ACLs. On Sophos Firewall, the relevant parts are Amazon VPC connections, IPsec profiles, XFRM interfaces, BGP, routes and firewall rules.

Plan before configuring

AWS Site-to-Site VPN should not be treated as a simple import of a downloaded example configuration. The AWS file is useful, but the production handover depends on routing, security groups, NACLs, firewall rules and tests with real traffic.

Define networks and target gateway

First decide which AWS-side gateway is used:

• Virtual Private Gateway for a classic single VPC.
• Transit Gateway for multiple VPCs, multiple sites or a larger routing design.
• Cloud WAN or other variants only when the AWS architecture explicitly requires them.

Document in advance:

• AWS VPC CIDR, for example 10.60.0.0/16
• relevant AWS subnets and route tables
• local networks behind Sophos Firewall, for example 172.16.20.0/24
• public IP address of Sophos Firewall or the upstream router
• routing mode: static or dynamic BGP
• local and AWS ASN when BGP is used
• expected test targets on both sides
• planned tunnel options, IKE version, preshared keys and lifetimes

Overlapping networks should be cleaned up before the VPN design is built. NAT over IPsec can work, but it makes route tables, security groups, logs and later troubleshooting harder.

Treat both tunnels seriously

AWS creates two tunnels per Site-to-Site VPN connection, each with a different AWS endpoint. Both tunnels should be configured and checked on Sophos Firewall. Building only one tunnel is convenient for a lab test, but it wastes AWS redundancy in production.

The expectation matters: the return path from AWS prefers one tunnel depending on routing and the AWS side, and can fail over when needed. This does not mean both tunnels are always used evenly. What matters is that both tunnels come up, BGP or static routes are correct and failover has been tested.

Static routing or BGP

AWS Site-to-Site VPN supports static routes and dynamic routing with BGP. BGP is usually the better choice when multiple prefixes, later expansion or Transit Gateway are involved. Static routes are simpler, but every network change must be maintained manually.

In practice:

• BGP needs matching ASN values on both sides.
• Sophos Firewall must advertise the intended local prefixes.
• AWS route tables must actually use propagated or static routes.
• Security groups and NACLs must also allow the traffic.
• Identical static and BGP routes can create unexpected priority behaviour.

Prepare AWS

The following steps describe the usual flow. Details differ between Virtual Private Gateway and Transit Gateway, but the principle is the same.

Create the customer gateway

The Customer Gateway describes the local Sophos side in AWS.

Enter:

1. Set a Name tag, for example cgw-sophos-hq.
2. Select routing: static or dynamic.
3. Enter the public IP address of the Sophos side.
4. For BGP, enter the local Sophos ASN.
5. Create the resource and keep tagging consistent.

If Sophos Firewall sits behind a router or provider device, it must be clear which public IP AWS sees and whether NAT-T works cleanly. The IP entered in AWS must match the real tunnel negotiation.

Create or select the target gateway

For a single VPC, a Virtual Private Gateway is typically created and attached to the VPC. Larger AWS environments often use a Transit Gateway.

Check:

• The gateway is attached to the right VPC or Transit Gateway.
• The AWS-side ASN does not collide with the Sophos ASN.
• VPC or Transit Gateway route tables are planned.
• The subnets used for testing use the correct route table.

Create the Site-to-Site VPN connection

Next, create the Site-to-Site VPN connection in AWS.

Important points:

• Select the correct target gateway type.
• Select the customer gateway.
• Set Routing Options to static or dynamic.
• For static routing, enter the local prefixes.
• Review Tunnel Options deliberately, especially IKE version, encryption, integrity, DH/PFS and DPD.
• Document preshared keys per tunnel or let AWS generate them intentionally.

After creation, download the configuration file. Vendor can be Sophos, platform Sophos Firewall and a suitable software version. The file is a good starting point, but it does not replace a technical review of the tunnel options.

Check route tables, security groups and NACLs

A green VPN tunnel in AWS does not yet mean that an EC2 instance is reachable.

For validation, check:

• The VPC route table has a route to the local network through the Virtual Private Gateway or Transit Gateway.
• With Virtual Private Gateway, route propagation is enabled or the route is set statically.
• Transit Gateway route tables contain the right attachments and propagations.
• The target instance security group allows the required traffic from the local network.
• Network ACLs allow the forward and return path.
• The instance operating-system firewall does not block the test.

This part is often missed because Sophos and AWS can both show a connected tunnel even when the instance does not respond because of a security group or return-route issue.

Configure Sophos Firewall

Sophos offers two practical paths for AWS: import through Site-to-site VPN > Amazon VPC or manual setup as a route-based IPsec connection. For many AWS setups, the import is the cleanest starting point, but the generated objects must still be reviewed.

Import the AWS configuration

Sophos Firewall can import the Amazon VPC connection from the downloaded AWS configuration file.

Steps:

1. Open Sophos Firewall.
2. Go to Site-to-site VPN > Amazon VPC.
3. Select Use VPC configuration file.
4. Upload the AWS configuration file.
5. Start the import.
6. Check the created connections, IPsec profiles, XFRM interfaces and BGP settings.

If the firewall is behind a NAT device, review the configuration file or resulting Sophos configuration especially carefully. Sophos notes that the file contains values per tunnel and both tunnels must be considered.

Check IPsec profile and tunnels

After import, or when configuring manually, do not rely blindly on status alone.

Check:

• Both AWS tunnels exist.
• IKE version matches the AWS configuration.
• Encryption, authentication, DH group, PFS and lifetimes match per tunnel.
• The preshared key is correct per tunnel.
• Gateway type and remote gateway point to the relevant AWS tunnel endpoints.
• XFRM interfaces exist and are named clearly.

If AWS tunnel options are changed later, the Sophos side must match. One-sided changes often cause phase 1 or phase 2 failures.

Configure BGP or static routes

With BGP, check under Routing > BGP that local ASN, neighbour, remote ASN and advertised networks are correct. Under Routing > Information > BGP, Neighbors, Summary and Routes should show the expected values.

With static routing, routes to AWS networks must point to the correct XFRM interface. AWS must also know the local prefixes, either through static VPN routes or through the relevant route table.

For both variants, routing must be correct in both directions. A tunnel can be connected while the return path goes through the internet, a NAT gateway or the wrong route table.

Create firewall rules

Route-based IPsec does not automatically create production-quality firewall rules. Create and log them deliberately.

Recommended:

1. Create a rule from the local network to AWS destinations.
2. Allow the reverse direction only if AWS must actively reach local systems.
3. Scope source, destination and services tightly.
4. Enable logging for validation.
5. Check rule position before broad drop or catch-all rules.

If the expected rule does not match, use Sophos Firewall rule not matching: how to find the cause.

Validate the connection

Validation should always include both platforms and real application traffic. A green tunnel status alone is not enough.

Check AWS

In AWS, check:

• VPC > Site-to-Site VPN Connections > Tunnel Details shows both tunnels.
• Tunnel status is UP.
• With BGP, routes are visible.
• The VPC or Transit Gateway route table contains expected routes.
• Security groups and NACLs allow the test.
• CloudWatch metrics or VPN logs do not show repeated IKE or DPD issues.

Check Sophos Firewall

On Sophos Firewall, check:

• Site-to-site VPN > Amazon VPC or Site-to-site VPN > IPsec shows active tunnels.
• Routing > Information > BGP shows neighbours and learned routes when BGP is used.
• Network > Interfaces shows XFRM interfaces.
• Log Viewer shows the expected firewall rule.
• Packet Capture confirms ingress and egress interface when logs are not enough.

Choose test traffic carefully

A test should use a concrete source host, target host and service, for example ICMP, RDP, SSH, HTTPS or DNS. If ICMP is blocked, ping is not meaningful. A test with the service that will actually be used later is better.

Common errors

AWS VPN errors often look like IPsec problems even when routing or AWS security controls are the cause. These cases are especially common.

Only one tunnel is active

One tunnel is enough for an initial test, but not for clean operations. Both AWS tunnels have their own endpoints and parameters. Check preshared key, IKE/IPsec parameters, XFRM interface, BGP neighbour and AWS status per tunnel.

BGP does not come up

If the tunnel is connected but BGP does not peer, first check ASN, neighbour IP, local advertisements and inside tunnel addresses. Sophos also documents cases where BGP peering does not form automatically even though the AWS VPC tunnel is connected.

Tunnel is green, instance is unreachable

The cause is often outside IPsec: wrong AWS route table, missing route propagation, security group, NACL, operating-system firewall, wrong source network or missing Sophos firewall rule.

Return path is wrong

AWS must know the return path to the local network through VPN. Locally, the return path to the AWS VPC must go through XFRM or BGP. Asymmetric routing can look normal in tunnel status but break real sessions.

MTU or fragmentation affects applications

AWS Site-to-Site VPN and IPsec overhead can expose MTU problems. If small tests work but larger transfers or specific applications hang, check MSS/MTU, fragmentation and packet captures.

Operations and review

After go-live, the tunnel should be moved into normal operations. This includes an owner, a documented preshared-key process, a change window for IPsec parameters, tunnel monitoring, regular failover tests and a clear process for AWS or ISP changes.

Whenever VPC CIDRs, Transit Gateway routing, route tables, security groups, local networks or BGP advertisements change, repeat VPN validation. Cloud VPN is not a one-time click, but part of the network architecture.

FAQ