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. In the AWS console, go to VPC > Virtual private network (VPN) > Customer gateways and choose Create customer gateway.
2. Set Name tag, for example cgw-sophos-hq.
3. If you plan to use BGP, set BGP ASN to the exact local Sophos ASN. AWS also shows this field for statically routed connections, but static routing does not establish BGP peering.
4. Under IP address, enter the static, internet-routable address of the Sophos side. If the firewall is behind an upstream NAT device, enter that NAT device’s public IP address for the AWS Customer Gateway, not the address of the Sophos WAN interface behind it.
5. Optionally enter a clear device label under Device, then choose Create customer gateway.

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. For the Customer Gateway, allow UDP 500 and, when NAT-T is used, UDP 4500 between the local network and the AWS Site-to-Site VPN endpoints. Configure the upstream NAT/firewall to allow and forward those ports between the Sophos WAN interface and both AWS tunnel endpoint IP addresses from the configuration file.

Create or select the target gateway

For a single VPC, a Virtual Private Gateway is typically created under VPC > Virtual private network (VPN) > Virtual private gateways and then attached using Actions > Attach to 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, go to VPC > Virtual private network (VPN) > Site-to-Site VPN connections and choose Create VPN connection.

Important points:

• Under Target gateway type, select the planned Virtual Private Gateway or Transit Gateway.
• Under Customer gateway, choose Existing and select the customer gateway created earlier.
• Set Routing options to Dynamic (requires BGP) or Static; under Static IP prefixes, enter only the local prefixes AWS must reach through the VPN.
• Review Tunnel Options deliberately, especially IKE version, encryption, integrity, DH/PFS and DPD.
• Document preshared keys per tunnel or let AWS generate them intentionally.

For dynamic routing, Sophos requires Local IPv4 Network Cidr and Remote IPv4 Network Cidr in the AWS connection to both be 0.0.0.0/0 so that BGP peering can form. If a Local AS is already configured on the firewall, enter that exact ASN for the AWS Customer Gateway.

After creation, select Download configuration. For automatic Sophos import, select Vendor Sophos, Platform Sophos Firewall, Software v19+ and the IKE version actually planned. The file is only a sample configuration: algorithms, DH groups, certificates and the IP family must match the production design. Behind NAT, before importing, enter the local address of the Sophos WAN interface in both customer-gateway-side tunnel_outside_address blocks. Leave the AWS-side outside endpoints unchanged; do not indiscriminately replace every XML block with the same name. In the AWS Customer Gateway, however, retain the public address of the upstream NAT device. For static routes, select Generic and configure manually. Dynamic BGP can also be configured manually using the Generic download described below; Sophos import is not the only BGP option.

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

Under Site-to-site VPN > Amazon VPC, Sophos Firewall can import the connection using either Use AWS security credentials or Use VPC configuration file. For the credential method, use a dedicated AWS IAM user with the permissions required for the site-to-site VPN settings; protect and rotate its access key and secret key like other administrative secrets.

The import is a snapshot. If tunnel options or other connection values change in AWS, import the settings again and then repeat the complete validation. An earlier import does not automatically track the AWS configuration.

The following procedure uses 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.

The import creates IPsec profiles, BGP settings and XFRM interfaces. Then add the local prefixes under Routing > BGP > Networks. Under Administration > Device access, IPsec must be enabled for WAN and Dynamic Routing for VPN. These settings permit tunnel and routing control traffic; they do not replace a firewall rule for payload traffic.

Behind NAT, check that the customer-gateway-side tunnel_outside_address in each of the two tunnel sections contains the local Sophos WAN address. Do not change AWS-side outside addresses; the public NAT address remains the AWS Customer Gateway address. If the mapping is unclear, do not activate the file or imported objects; first identify the customer side and AWS side unambiguously.

Configure two IPv4 VGW tunnels manually with BGP

This alternative describes an IPv4 connection to a Virtual Private Gateway attached to the VPC, using Dynamic (requires BGP). It is not an IPv6/Transit Gateway/Cloud WAN runbook, nor a blanket statement that AWS does not support IPv6. AWS permissions, local admin rights, reachable outside endpoints, non-overlapping networks and an approved return path are prerequisites. Do not activate an import and a parallel manual configuration for the same routes at the same time.

1. In AWS, open Download configuration for the intended VPN connection: Vendor Generic, Platform Generic, Software Vendor agnostic, IKE version ikev2. This explicitly also applies to manual dynamic BGP. The file contains PSKs: store it encrypted and with restricted access.
2. For each tunnel separately, record the outside endpoint, PSK, inside CIDR, customer inside address, AWS inside address and ASNs from the configuration actually generated. Use two different AWS-accepted /30 networks from 169.254.0.0/16; do not use reserved ranges or ranges already in use. The following mapping is a readable planning example, not an AWS allocation:

Mapping table: the outside IP establishes IPsec; the inside IP addresses XFRM and BGP. Use only the addresses actually supplied by AWS: do not infer your own allocation from the order of the demo addresses. The SFOS XFRM address is the customer inside address, never the AWS inside address or the public IP. The BGP neighbour is the AWS inside address, not the outside endpoint.

3. Under Profiles > IPsec profiles > Add, create a custom profile with a unique name. A bounded example for tunnels configured this way on both sides is IKEv2, Phase 1 AES256 / SHA2 256 / DH 14 (DH2048) and Phase 2 AES256 / SHA2 256 / PFS 14 (DH2048). Enable Re-key connection; use Key negotiation tries 0 and leave Use strict profile disabled only if the approved operating plan specifies this. The selected algorithms and DH/PFS groups must form a common permitted proposal, not merely share the same profile name.
4. Document lifetimes and rekey/DPD separately. A historical example specifies AWS Phase 1 28800 seconds, but SFOS Key life 28000; Phase 2 3600 on both sides, Rekey Margin 360 and Fuzz 50 per cent. Different local IKEv2 rekey timers are not automatically a proposal error and are not evidence of tested interoperability. Do not silently adopt a contradictory timer as a universal default: use the actually configured AWS values and an approved SFOS rekey plan aligned with them; stop and clarify if the conditions are unclear. One DPD example is AWS Restart, with SFOS DPD enabled, check interval 30, response timeout 120 seconds and Re-initiate. These values are a profile example to be checked, not a universal requirement. Confirm rekey/DPD behaviour in your own change window before production use.
5. Under Site-to-site VPN > IPsec > Add, create a separate connection for each tunnel with Connection type Route-based (Tunnel interface), IP version IPv4 and Gateway type Initiate the connection. Under Profile, select the custom profile just checked, rather than blindly selecting another default profile named IKEv2. Set Authentication type to Preshared key and enter the exact PSK for that tunnel. Listening interface is the local WAN interface; Gateway address is the respective AWS outside endpoint. Set local/remote IKE IDs only according to the actual expected identity plan; never use arbitrary IPs. Behind NAT, the local WAN address must not be equated with the public Customer Gateway address. Select Activate on save only in the approved window after checking; save and activate both connections.
6. Under Network > Interfaces, open the XFRM associated with each connection and check the connection link. Under IPv4/netmask, enter that tunnel’s customer inside IP and /30 (255.255.255.252). Use the second XFRM’s own inside IP; do not swap the mappings.
7. Under Routing > BGP > Global configuration, retain the Local AS already in use or set the approved Customer Gateway ASN. Use a unique, stable Router ID from your own plan. Do not overwrite an existing global ASN for this VPN; AWS must use the same local ASN value. Do not copy an ASN range or demo ASN without checking: first verify availability, AWS acceptance and absence of conflicts. Under Neighbors, create an IPv4 neighbour for each AWS inside IP, with Remote AS equal to the actual VGW ASN.
8. Under Routing > BGP > Networks, advertise only the approved locally reachable prefixes. Under Administration > Device access, allow IPsec for WAN and Dynamic Routing for VPN; do not add blanket LAN access if no local routing peer is planned there. Opening BGP TCP 179 as payload traffic globally or between all LAN/VPN networks does not replace this control-plane permission. Also create the tightly restricted data rules described in the following section.
9. For each neighbour, under Routing > Information > BGP > Neighbors, check for Established and the expected learned and advertised prefixes. In AWS, under Tunnel Details, check that both tunnels are UP and check BGP routes; check VGW route propagation for the affected subnet route tables. Only then test permitted application traffic and an unauthorised source. During the agreed window, disable one tunnel in a controlled manner, verify that the expected route/application remains available through the other, reactivate it and recheck both neighbour relationships; do not claim redundancy acceptance without an actual failover test.

For IPsec errors, first check each tunnel’s endpoint, PSK, proposals, IDs and NAT-T; for BGP Active, first check XFRM inside addresses, ASN, peer activation and Device Access. A temporary static route with ping is not a general BGP repair and may conceal the wrong path. If existing routes disappear or the lifetime/ID mapping is unclear, do not try further values; stop the new configuration and compare it with the saved state. Validate the tunnel and application paths on the intended appliance before production rollout.

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 and PFS form a proposal permitted by both sides for each tunnel; lifetimes and local rekey timers are checked separately against the approved plan, not solely for numerical equality.
• 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, the Sophos proposals must remain compatible, and the separately documented rekey/DPD timers must align with the approved operational plan. One-sided changes to the algorithm, DH/PFS, PSK or identity can prevent phase 1 or phase 2 from establishing; different local IKEv2 lifetimes alone do not demonstrate such a proposal mismatch.

Configure BGP or static routes

With BGP, check under Routing > BGP that local ASN, neighbour, remote ASN and advertised networks are correct. Configure BGP on Sophos Firewall explains the complete setup and validation. 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. Under Rules and policies > Firewall rules > IPv4 > Add firewall rule > New firewall rule, create the local-to-AWS rule: set Source zones to LAN, Source networks and devices to the local network object, Destination zones to VPN, and Destination networks to the AWS network object.
2. Under Services, select only the services actually required; use Any only temporarily for isolation and then replace it.
3. Allow the reverse direction with Source zones VPN and Destination zones LAN only if AWS must actively reach local systems.
4. Enable Log firewall traffic 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. A narrowly defined Sophos case applies when the AWS VPC tunnel is active and connected on the firewall, the BGP neighbour remains in Active, AWS shows the VPN as down while IPsec is up, and the running BGP configuration contains no bgp default ipv4-unicast.

Only when all these characteristics match, record the current BGP configuration, Local AS and neighbour IP. Then open the BGP console through 3. Route Configuration > 1. Configure Unicast Routing > 3. Configure BGP and activate exactly the affected AWS neighbour:

enable
conf t
router bgp <as-number>
neighbor <ip-address> activate
write

Replace <as-number> with the local Sophos ASN and <ip-address> with the inside tunnel address of the affected AWS neighbour. Then recheck the BGP summary, learned and advertised prefixes, AWS tunnel status and real traffic. If no bgp default ipv4-unicast is absent or the AWS addresses and ASNs do not match, do not apply these commands. The command comes from the narrowly scoped SFOS 22 troubleshooting procedure for Amazon VPC connections and is not a general BGP repair.

Before conf t, document the current BGP configuration and the recovery method approved for your environment. If the neighbour does not reach Established afterwards or existing routes disappear, do not improvise; use only that pre-tested recovery method. If no such method exists, end the diagnosis before making the change and escalate to Sophos Support.

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.

Roll back new tunnels and routes selectively

Before the change, save a backup, IPsec profiles and tunnel mappings, XFRM addresses, BGP neighbours/advertisements, firewall rules and AWS route tables including propagation. If advertisements are unexpected, the destination is wrong or existing traffic is interrupted, first withdraw the newly introduced prefixes or disable the new connection, and revert only the changed rules/routes to the documented safe state. Do not delete or reset existing BGP neighbours, the global ASN or shared gateways/VPCs/subnets. Recheck the intended existing routes, permitted applications and blocking of an unauthorised source. Without an approved return path, stop the change before activation.

FAQ