Set up Sophos Firewall Site-to-Site IPsec VPN

A Site-to-Site IPsec VPN connects two sites, or a Sophos Firewall and a third-party firewall, through an encrypted tunnel. In practice, such tunnels rarely fail because of a single setting in the interface. More often, the cause is unclear networks, mismatched IPsec profiles, missing firewall rules, NAT edge cases or a return path that was forgotten on one side.

Quick flow: Choose the tunnel type, align the profile and IDs, create the connection, route the XFRM interface for route-based Any-to-Any, configure firewall and NAT rules, then validate the tunnel with real traffic, logs and Packet Capture.

This procedure applies to Sophos-to-Sophos and third-party connections between a head office, branch or cloud gateway. Microsoft Azure and AWS require additional provider-specific details: Connect Sophos Firewall to Azure VPN Gateway and Connect Sophos Firewall to AWS Site-to-Site VPN. For Remote Access by individual users, use the comparison between Sophos Connect and SSL VPN instead. If an existing tunnel is already green but no traffic flows, see Sophos Firewall IPsec VPN troubleshooting.

If the connection is exclusively between two Sophos Firewalls and the branch should establish the tunnel as a client to a head office with a stable public address, SSL Site-to-Site VPN is a simpler alternative. For third-party peers, redundancy, dynamic routing or growing networks, route-based IPsec remains the more flexible choice.

For several firewalls managed by Sophos Central, an SD-WAN connection group can generate the route-based tunnels, XFRM interfaces, routes, and optional rules automatically. This replaces neither topology planning nor local traffic validation.

Choose policy-based or route-based

Before configuration, decide whether the tunnel should be policy-based or route-based. Current SFOS versions separate these terms more clearly than older guides, which sometimes still refer to Site-to-Site or Tunnel Interface.

• Policy-based IPsec: fits simple site connections with clearly defined local and remote networks. It is controlled primarily through local and remote subnets in the IPsec connection and through firewall rules. Sophos creates separate Phase 2 tunnels for the combinations of local and remote subnets.
• Route-based IPsec with Traffic Selectors: also uses local and remote subnets, but creates a dedicated XFRM interface. Sophos creates the route automatically; do not assign an IP address or separate routes to the XFRM interface. WAF is not supported with this variant.
• Route-based IPsec Any-to-Any: is the most flexible option for growing networks, SD-WAN, dynamic routing and dual-stack designs. Routes and firewall rules, rather than subnets in the IPsec connection, decide which packets enter the tunnel.

Sophos recommends route-based VPN for new designs. Any-to-Any is particularly flexible for growing networks because route changes do not disconnect the tunnel. Changes to subnets or Traffic Selectors, however, interrupt existing connections. Both tunnel endpoints must use the same type: policy-based at one end and route-based at the other is not supported.

For OSPF or BGP through the tunnel, route-based Any-to-Any with addressed XFRM interfaces is the transparent design. Before upgrading an older policy-based setup, check whether VPN networks are advertised through redistribute kernel; SFOS 22: IPsec routes and redistribute kernel explains the version change and the safe migration framework.

Requirements and planning data

Document at least the following before setup:

• Local endpoint: the Sophos Firewall WAN interface and the address through which the peer reaches this interface.
• Remote Gateway: public IP address or DNS hostname of the peer.
• Gateway type: typically Respond only at the head office and Initiate the connection at the branch.
• IP version: IPv4, IPv6 or Dual. Dual is available only for route-based tunnel interfaces with Any-to-Any as the local and remote subnets. With Dual, IPv4 and IPv6 firewall rules must be planned separately.
• Local networks: for example 172.16.10.0/24 and 172.16.20.0/24.
• Remote networks: for example 10.20.30.0/24.
• VPN type: policy-based or route-based. The Host-to-host Connection type also exists, but it is not the focus of this site guide.
• Listening interface: WAN interface of the local firewall. A bridge interface cannot be used.
• IKE version: preferably IKEv2 if the peer supports it.
• Authentication type: Preshared key, Digital certificate or RSA key.
• Local ID and Remote ID: especially important with FQDNs, dynamic peers, NAT-T or a wildcard gateway.
• IPsec profile: Encryption, Authentication, DH Group, PFS and Key life.
• Firewall rules: permitted sources, destinations and services.
• NAT: no NAT, or SNAT/DNAT because of overlapping networks or provider requirements.
• Operations: owner, maintenance window, test plan, monitoring and fallback path.

⚠️ Do not implement a Site-to-Site VPN without a documented return path. If the local firewall sends traffic into the tunnel but the peer has no return route or expects NAT differently, the tunnel often appears healthy even though applications do not work.

Networks, profile, IDs and certificates

Local and remote networks must not overlap unintentionally. Common default networks such as 192.168.0.0/24, 192.168.1.0/24 or reused branch networks are particularly problematic. Overlapping networks require a deliberate NAT design. Using the same address range on both sides and translating it “somehow” later creates tunnels that are difficult to maintain.

A clean IP addressing plan is therefore worthwhile for new sites. If VLANs or zones are not yet modelled clearly, see Configure Sophos Firewall zones and interfaces.

Both sides must use compatible Phase 1 and Phase 2 parameters. These include encryption, authentication, DH group, PFS and lifetime. For connections to third-party firewalls, the easiest approach is often to document a shared profile first and then configure both sides.

With IKEv2, Sophos can use unique Preshared Keys for each Local ID and Remote ID combination. IKEv1 is more restricted because only one PSK applies per gateway combination. In environments with multiple tunnels to the same peer, prefer IKEv2 with clearly defined IDs.

NAT Traversal is always active on Sophos Firewall. If one side is behind a router or provider NAT, IDs become more important because the public gateway address does not uniquely identify the peer. The Local ID on one side must match the Remote ID expected by the other. DNS, IP or email IDs do not need to resolve publicly, but their formats and values must match crosswise.

With Digital certificate, the certificate formats and roles on both sides must match exactly. Sophos does not support ECDSA certificates for IPsec connections; RSA certificates are required. Do not use a public CA indiscriminately as the Remote CA Certificate because that places too much trust in third-party certificates. RSA key is a separate Authentication type: both firewalls exchange their public keys and must use the same PKCS1 or DNS format.

Changing the local Default CA on a Sophos Firewall is a trust-anchor change, not a cosmetic certificate edit. Peers with an imported Default.pem and locally signed certificates must be migrated in a controlled manner. Renew the Sophos Firewall Default CA safely explains inventory, the maintenance window, testing, and recovery.

If the CA revokes certificates before they expire, the current revocation list also belongs in the operations plan. The separate workflow covers CRL import, nextUpdate, and a controlled negative test on Sophos Firewall.

If a tunnel does not come up, NO_PROPOSAL_CHOSEN, ID errors or authentication errors are typical indicators. The Test and troubleshoot the tunnel section starts with the appropriate isolation steps.

Set up policy-based IPsec

Policy-based IPsec is the classic option for simple Site-to-Site connections. The local and remote networks are defined directly in the IPsec connection.

1. Check or create the IPsec profile

Menu path:

Profiles > IPsec profiles

First check whether an existing profile matches the peer. If a dedicated profile is required, give it a clear name, for example IPsec_IKEv2_AES256_G14. The name should remain understandable later when several tunnels and peers exist.

Document at least:

• IKE version
• Phase 1 Encryption and Authentication
• DH Group
• Phase 2 Encryption and Authentication
• PFS
• Key life

For third-party firewalls, the peer should confirm the same values in writing. A screenshot alone is often insufficient because individual fields may have different names depending on the vendor.

How Phase 1, Phase 2, PFS, lifetimes, rekeying, and DPD work together is explained in Understand and securely configure Sophos Firewall IPsec profiles.

2. Add the IPsec connection

Menu path:

Site-to-site VPN > IPsec

Create a new IPsec connection and choose Policy-based as the Connection type. Then set the basic data:

• Tunnel name, for example branch-zurich
• IP version, usually IPv4
• Gateway type, for example Respond only at the head office or Initiate the connection at the branch
• Listening interface as the local WAN interface
• Peer Gateway address as an IP address or DNS hostname
• Authentication type: Preshared key, Digital certificate or RSA key
• Local ID and Remote ID if required
• IPsec profile
• Local subnet
• Remote subnet

With policy-based IPsec, no more than one side of the Traffic Selectors may be set to Any. With multiple specific local and remote networks, Sophos creates one Phase 2 SA for each combination.

With Respond only, the wildcard address * can be useful when several branches or dynamic peers connect to the head office. At least one Local ID or Remote ID must then be set; both IDs are usually useful for unambiguous assignment. The Local ID on one side corresponds to the Remote ID expected by the other. Initiate the connection does not support a wildcard address, so define the peer there as an IP address or DNS hostname.

Use a strong, unique Preshared Key and document it securely. Reusing an old shared default key across several sites is an unnecessary operational risk.

The advanced User authentication mode settings apply only to IKEv1 profiles with XAuth logic, such as very old client-server designs. Do not infer an additional authentication step from them for normal Site-to-Site connections with IKEv2. Likewise, do not plan deprecated idle connection settings as a modern operating design.

3. Activate the tunnel

When saving, Activate on save can be selected. In production environments, do this within a defined maintenance window when the peer is reachable and both sides can check logs.

After saving, the list shows two relevant states:

• whether the connection is active
• whether the tunnel is actually established

An active entry is not automatically an established tunnel. With several local or remote networks, there may also be multiple Security Associations.

Set up route-based IPsec

Route-based IPsec separates VPN negotiation and the data path through a dedicated XFRM interface. Whether this interface is addressed and routed manually depends on the selected variant.

1. Create the connection as route-based

Menu path:

Site-to-site VPN > IPsec

Choose Route-based (Tunnel interface) for the connection. The gateway, authentication, ID and IPsec profile parameters must still match the peer. You must also understand which XFRM interface is created afterwards and how it is routed.

2. Implement Any-to-Any or Traffic Selectors

Sophos shows the generated XFRM interface under the physical interface used in:

Network > Interfaces

The XFRM interface always remains assigned to the VPN zone. The two variants are configured differently.

Any-to-Any and Dual

When both subnets are set to Any, or Dual is used, the XFRM interface receives a transfer IP address. It then requires a static route, SD-WAN Route or dynamic route through BGP or OSPF. With Dual, separate IPv4 and IPv6 firewall rules are required.

Routes and firewall rules decide which traffic enters the tunnel. A simple static route can point directly to the XFRM interface. For multiple links, SLA checks or certain failover designs, a Custom Gateway with the peer’s XFRM IP address is additionally created and used in an SD-WAN Route.

Any-to-Any tunnels can control multiple XFRM gateways directly through SD-WAN and SLA checks; no additional VPN failover group is required. By contrast, policy-based tunnels and route-based tunnels with Traffic Selectors use an IPsec failover group for redundant connections. The linked procedure explains member order, Health Check, Automatic failback, and the controlled outage test. The group disables DPD for the assigned connections and sets Key negotiation tries to 3.

Check three points after saving:

1. The XFRM interface is visible under Network > Interfaces and has the planned transfer IP address.
2. The route to the remote network points directly to the XFRM interface or, in a gateway/SD-WAN design, to the appropriate XFRM gateway.
3. Firewall rules permit only the planned directions and services.

Traffic Selectors

With specific Local and Remote subnets, Sophos also creates an XFRM interface, but no IP address or separate routes may be assigned to it. The static route is created automatically as soon as the tunnel is established. Any on only one side with a specific selector on the other is not supported.

This variant is suitable for small, clearly defined networks and simplifies XFRM diagnostics. However, WAF over route-based IPsec with Traffic Selectors is not supported.

An Any-to-Any tunnel cannot be changed directly to specific Traffic Selectors. Clone or recreate the connection and then switch over in a controlled manner.

3. Consider XFRM and MTU

Route-based VPNs are more prone to misunderstandings around routing, MTU and MSS. If small tests work but larger transfers hang, do not change the IPsec profile immediately. First check MTU, MSS, fragmentation and the actual path. The appropriate procedure is described in Check Sophos Firewall MTU and MSS for VPN problems.

Firewall rules, NAT and Device Access

Firewall rules and automatic rules

After IPsec configuration, rules are required for production traffic. Without matching rules, the tunnel may be green but applications will not work.

Menu path:

Rules and policies > Firewall rules

Typical rules:

• Local network to remote network: for example LAN to VPN.
• Remote network to local server network: for example VPN to Server.
• Management or monitoring: permit only defined administration or monitoring systems.
• DNS, AD, RDP, HTTPS: permit only required services, not blanket Any.

XFRM interfaces always belong to the VPN zone. If both directions are used, corresponding inbound and outbound rules are required. Separate rules with logging show more clearly during acceptance which side may reach which services. The general structure is described in Create and securely check Sophos Firewall rules.

The Create firewall rule option creates separate rules with the Incoming and Outgoing prefixes at the top of the rule list. Afterwards:

• Check the rule position.
• Narrow Source and Destination.
• Reduce Any to the required Services.
• Enable Log firewall traffic for rollout and troubleshooting.
• Select IPS, Web, Application Control and other Security Features deliberately.
• Give the rule a clear name, for example LAN_to_Branch_Zurich.

⚠️ Automatically created firewall rules are a starting point, not a finished security design. Especially for site tunnels to server networks, reduce services, sources and destinations after the first test.

Sophos cannot create rules automatically for route-based Any-to-Any. With Dual, IPv4 and IPv6 rules are created separately. If a branch’s Internet traffic should pass through the head office, a separate NAT and security design is also required.

Plan NAT by tunnel type

NAT is not prohibited with IPsec, but it must have a clear reason. Typical cases are overlapping networks, cloud requirements or third parties that accept only specific source addresses.

Menu path:

Rules and policies > NAT rules

Answer these questions before creating a NAT rule:

• Does the peer expect original IP addresses or translated addresses?
• Are there overlapping networks?
• Is NAT handled in the IPsec connection or through separate NAT rules?
• Is the return direction documented?
• Does Log Viewer show the expected Source and Destination after NAT?

The NAT logic differs by VPN type:

• With policy-based IPsec and route-based VPN with Traffic Selectors, NAT for overlapping networks can be configured directly in the IPsec connection.
• With route-based Any-to-Any, use SNAT and DNAT rules under Rules and policies > NAT rules.
• With overlapping networks, both sides must understand the same translation plan. One-sided NAT without return-path planning often produces green tunnels with unusable traffic.

⚠️ With route-based IPsec using Traffic Selectors, the XFRM interface has no IP address. If this traffic matches a MASQ SNAT rule, the firewall drops the packets. For overlapping networks, use the NAT setting in the IPsec connection and ensure that no MASQ SNAT rule matches this traffic.

Since SFOS 22, policy-based IPsec creates the VPN route in the backend. A manual ipsec_route is relevant only for certain translated, forwarded traffic and is not a standard step; system-generated traffic does not require it. Further NAT fundamentals are covered in Understand Sophos Firewall NAT rules.

Device Access for incoming IPsec

For incoming IPsec requests, the firewall must be able to accept IPsec traffic on the appropriate WAN zone. This is not handled by a normal LAN-to-WAN rule, but by the firewall’s local services.

Menu path:

Administration > Device access

IPsec must be allowed for WAN when the firewall accepts incoming requests, for example with Respond only. This does not replace rules for user traffic through the tunnel. At the same time, check whether WebAdmin, SSH, User Portal or VPN Portal are reachable too broadly. For hardening these local services, see Secure Sophos Firewall access: configure Device Access correctly.

Test and troubleshoot the tunnel

A good acceptance test checks more than the green status. It checks the actual data flow.

Define an acceptance matrix

Define a small acceptance matrix before the first test. This makes clear which connection must work and which connection should deliberately remain blocked.

Useful test cases:

• Local client network to remote server network: a typical application test, for example HTTPS, RDP, SMB, SQL or ICMP only as a basic test.
• Remote client network to local server network: check the opposite direction if the connection is used bidirectionally.
• DNS or AD through the tunnel: test only if these services should actually pass through the tunnel. Define the source, destination server and port precisely.
• Monitoring or backup: check whether the planned systems access from the correct direction and do not accidentally require Any rules.
• Blocked test: a deliberately unapproved port or network should be blocked. Otherwise, the rule base is too broad.
• Large transfer: for file transfers, RDP, VoIP or application problems, also monitor MTU/MSS and fragmentation.

For each test case, note the Source IP, Destination IP, Service, expected firewall rule, expected NAT rule and expected direction. After each test, compare Log Viewer, Packet Capture and byte counters. If only ping is tested, the tunnel has not yet been accepted.

1. Check the status

In the WebAdmin interface:

Site-to-site VPN > IPsec

Check:

• The connection is active.
• The tunnel status is established.
• With multiple networks, all expected Child SAs are established.

2. Check Log Viewer

Menu path:

Log viewer

Generate test traffic with a clear Source, Destination and Service. Then check which firewall rule matches in Log Viewer and whether NAT, Webfilter, IPS or other modules affect the traffic. The procedure is described in Test a firewall rule with Log Viewer, Policy Test and Packet Capture. Check recurring rekeys, disconnects and connection errors in the IPsec logs, not by interpreting the current SA status.

3. Packet Capture and Advanced Shell

If Log Viewer is insufficient, use Packet Capture with a narrow filter:

Diagnostics > Packet capture

Example filter:

host 172.16.10.25 and host 10.20.30.15

For VPN troubleshooting, check both directions. Outgoing packets without replies usually indicate a return-path, NAT or peer-side problem.

Advanced Shell

For deeper troubleshooting over SSH, open 5. Device Management > 3. Advanced Shell and check the current SA status:

ipsec statusall

Relevant points include:

• IKE SA established
• Child SA installed
• local and remote Traffic Selectors
• byte counters in both directions

If SSH is not yet prepared, see Connect to Sophos Firewall via SSH.

Current IPsec logs

The current SFOS 22 log overview separates the functions:

• strongswan.log: IPsec service and connections.
• charon.log: IPsec service and NAT in IPsec connections.
• ipsec_monitor.log: monitoring of the IPsec service.
• /log/ipsec_conn/ipsec_<connectionname>.log: activation, deactivation and connection through WebAdmin.
• xfrmi.log: XFRM interfaces for route-based IPsec.
• dgd.log: only additionally for VPN failover, SD-WAN, DGD or Link Load Balancing, not as a general IPsec log.

For complete log and XFRM diagnostics, see Sophos Firewall IPsec VPN troubleshooting.

Typical errors

• Tunnel does not come up: IKE version, profile, PSK, certificate, Local ID or Remote ID probably does not match. Check strongswan.log, the IPsec profile and the peer.
• Phase 1 is up, Phase 2 is not: local or remote networks, or the Phase 2 proposal, probably do not match. Check Traffic Selectors, subnets and PFS.
• Tunnel is green, but there is no access: a firewall rule, NAT, routing or the return path is probably missing. Check Log Viewer, Packet Capture and routing.
• Only one direction works: the peer does not know the return route or NAT is incorrect. Check the peer, NAT rules and byte counters.
• Small pings work, applications hang: MTU/MSS, fragmentation or a Security Feature is probably involved. Check MTU/MSS and Packet Capture.
• Route-based Any-to-Any does not work: the XFRM IP, gateway, route or firewall rule probably does not match. Check Network > Interfaces, routing and VPN-zone rules.
• Route-based with Traffic Selectors does not work: do not configure an IP address or manual route on the XFRM interface. Check the automatic route, selectors, VPN-zone rules and a possible MASQ rule.
• Several tunnels affect each other: overlapping networks or similar selector configurations are likely. Check tunnel objects, the failover group and routes.

Checklist

Before the change:

• Local and remote networks are unambiguous.
• Policy-based or route-based was chosen deliberately.
• The IPsec profile is aligned with the peer.
• The Preshared Key, certificates or RSA keys are documented securely.
• Firewall rules are planned, including direction, rule position, logging and services.
• With Create firewall rule, it is clear which automatically created rules must be revised.
• For route-based Any-to-Any, the XFRM IP, gateway, manual firewall rules and routes are planned.
• For route-based Traffic Selectors, no IP address or manual routes are planned on the XFRM interface.
• NAT is either excluded or deliberately documented.
• Device Access for incoming IPsec has been checked.
• The maintenance window, peer and fallback path are known.

After the change:

• The tunnel status is established.
• An acceptance matrix with at least one test per required direction is defined.
• Log Viewer shows the expected firewall rule.
• Packet Capture shows outbound and return traffic.
• Internal DNS and application access have been tested.
• Byte counters increase in both directions.
• NAT and the return path are aligned with the peer.
• The change is recorded in the network documentation.

Frequently asked questions