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 one checkbox in the interface. More often the issue is unclear networks, mismatched IPsec profiles, missing firewall rules, NAT edge cases or a return path that was forgotten on one side.

This article explains how to build a clean Site-to-Site IPsec tunnel on Sophos Firewall. The focus is planning, implementation and acceptance testing. If an existing tunnel is already green but no traffic flows, Sophos Firewall IPsec VPN troubleshooting is the better companion article.

When this article fits

This article fits classic site connections, for example:

• Head office to branch office
• Sophos Firewall to Sophos Firewall
• Sophos Firewall to third-party firewall
• Sophos Firewall to cloud gateway when no dedicated cloud assistant is used
• Migration from simple old policy-based tunnels to a documented current configuration

It does not cover Remote Access for individual users. For that, use Configure Sophos Connect on Sophos Firewall, Sophos Connect or SSL VPN: which Remote Access solution fits? and Migrate legacy Remote Access IPsec before SFOS 22 MR1.

Policy-based or route-based IPsec

Before configuration, decide whether the tunnel should be built as policy-based or route-based. In current SFOS versions, these terms are separated more clearly than in older guides, which sometimes still refer to Site-to-Site or Tunnel Interface.

For small, stable connections, policy-based IPsec is often the fastest to understand. For larger or dynamic site networks, route-based IPsec is usually cleaner because routing and VPN negotiation are separated more clearly. If multiple networks, SD-WAN, BGP, OSPF or cloud networks are involved, route-based IPsec should be checked first.

Requirements

Document this information before setup:

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

Plan before configuration

Keep networks unambiguous

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 especially problematic. If networks overlap, a deliberate NAT design is required. Using the same address range on both sides and translating it “somehow” later creates tunnels that are hard to maintain.

For new sites, a clean IP addressing concept is therefore worthwhile. If VLANs or zones are not modelled cleanly yet, configure Sophos Firewall zones and interfaces helps.

Align the IPsec profile

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, it is often easiest to record a shared profile in writing first and then configure both sides.

If a tunnel does not come up, NO_PROPOSAL_CHOSEN, ID errors or authentication errors are typical indicators. The structured analysis is covered in Sophos Firewall IPsec VPN troubleshooting.

Do not forget firewall rules

An IPsec tunnel alone does not allow production access. Traffic through the tunnel still needs matching firewall rules. For policy-based connections these are usually rules between LAN and VPN or between custom zones. For route-based designs, it depends on which zone the XFRM interface or the relevant path is assigned to.

During rollout, Log firewall traffic should be enabled in the affected rules. Otherwise, exactly the information needed later to see which rule allowed or blocked a test is missing. The general check flow is described in test a firewall rule with Log Viewer, Policy Test and Packet Capture.

Review automatically created rules deliberately

When creating a Site-to-Site IPsec connection, the Create firewall rule option can help create an initial rule set. It does not replace a security review. Sophos Firewall creates these rules at the top of the firewall rule list. In current SFOS versions, separate rules are created for incoming and outgoing traffic with the prefixes Incoming and Outgoing.

For operations, this means:

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

For route-based IPsec with Any-to-Any subnets, extra care is required. Automatic firewall rules cannot be created for such route-based designs. With dual IP versions, IPv4 and IPv6 rules must be planned separately. In these scenarios, firewall rules, XFRM interface, routes and tests should be built deliberately by hand.

Set up policy-based IPsec

Policy-based IPsec is the classic variant 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, it should be named clearly, for example IPsec_IKEv2_AES256_G14. The name must still be 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 lifetime

For third-party firewalls, the peer should confirm the same values in writing. A screenshot alone is often not enough because individual fields are named differently depending on the vendor.

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
• Local gateway or Listening interface
• Remote Gateway as IP address or FQDN
• Authentication type: Preshared Key or certificate
• Local ID and Remote ID if required
• IPsec profile
• Local subnet
• Remote subnet

For Preshared Keys, use a strong, unique key and document it securely. Reusing an old shared standard key across several sites is an unnecessary operational risk.

3. Activate the tunnel

When saving, Activate on save can be set. In production environments this should happen in 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 several Security Associations.

Set up route-based IPsec

Route-based IPsec separates VPN negotiation and routing more clearly. Sophos Firewall creates an XFRM interface. Static routes, SD-WAN routes or dynamic routing then decide which traffic goes through the tunnel.

1. Create the connection as route-based

Menu path:

Site-to-site VPN > IPsec

Choose Route-based (Tunnel interface) for the connection. The parameters for gateway, authentication, IDs and IPsec profile must still match the peer. In addition, it must be clear which XFRM interface is created afterwards and how it is routed.

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

Network > Interfaces

Depending on the design, the XFRM interface needs an IP address. Especially with Any-to-Any designs, dual IP version or more complex routing scenarios, interface addressing should be planned cleanly.

When Any-to-Any is used, the tunnel selector alone no longer decides which traffic goes through the tunnel. Routes and firewall rules then become the central control point. This is flexible, but also error-prone: a rule that is too broad can allow more traffic than intended, while a missing route can make the tunnel look green even though user traffic does not flow.

2. Set routing

For route-based VPN, the IPsec connection alone is not enough. A route to the remote network is required:

• static route to the XFRM interface
• SD-WAN Route with matching gateway or profile
• dynamic route via BGP or OSPF if the design is built for it

For simple setups, a static route is often sufficient. If several WAN links, SLA checks or failover paths are used, an SD-WAN Route is more appropriate. The general context for SD-WAN, Reply Packets and system-generated traffic is covered in check Sophos Firewall SD-WAN routing for Reply Packets and System Traffic.

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 real path. The appropriate flow is described in check Sophos Firewall MTU and MSS for VPN problems.

Create firewall rules

After IPsec configuration, rules are needed 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:

Good practice:

• Rule name with tunnel or site, for example LAN_to_Branch_Zurich.
• Set Source and Destination as narrowly as possible.
• Define Services specifically.
• Enable logging during rollout and troubleshooting.
• Check rule position.
• Set protection features deliberately instead of inheriting them by chance.

If branch Internet traffic should be routed through headquarters, an intentional NAT and security concept is also required. That is a different design from a simple site connection for internal networks.

Plan NAT deliberately

NAT is not forbidden with IPsec, but it must be clearly justified. Typical cases are overlapping networks, cloud requirements or third parties that accept only specific source addresses.

Menu path:

Rules and policies > NAT rules

Before creating a NAT rule, answer these questions:

• Does the peer expect original IP addresses or translated addresses?
• Are there overlapping networks?
• Is NAT solved 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?

For policy-based edge cases with NAT, a manual IPsec route on Sophos Firewall can become relevant. This is not a standard step for every tunnel.

Device Access and WAN access

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

Menu path:

Administration > Device access

IPsec must be allowed there for the required zone. At the same time, check whether other local services such as WebAdmin, SSH, User Portal or VPN Portal are reachable too broadly. For hardening these local services, secure Sophos Firewall access: configure Device Access correctly is the central article.

Test the tunnel

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

1. Check status

In the WebAdmin interface:

Site-to-site VPN > IPsec

Check:

• The connection is active.
• Tunnel status is established.
• With multiple networks, all expected Child SAs are established.
• No recurring reconnects or errors are visible.

2. Check Log Viewer

Menu path:

Log viewer

Generate test traffic with a clear Source, Destination and Service. Then check in Log Viewer which firewall rule matches and whether NAT, Webfilter, IPS or other modules influence the traffic.

3. Use Packet Capture

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

Diagnostics > Tools > Packet capture

Example filter:

host 172.16.10.25 and host 10.20.30.15

For VPN troubleshooting, it is important to check both directions. Outgoing packets without a reply usually indicate a return-path, NAT or peer-side problem.

4. Use CLI only with a clear purpose

For deeper analysis, the Advanced Shell can be used via SSH:

ipsec statusall

Relevant points include:

• IKE SA established
• Child SA installed
• local and remote networks
• byte counters in both directions
• recurring rekey or disconnect messages

If SSH is not prepared yet, connect to Sophos Firewall via SSH helps.

Typical errors

Checklist

Before the change:

• Local and remote networks are unambiguous.
• Policy-based or route-based was chosen deliberately.
• IPsec profile is aligned with the peer.
• Preshared Key or certificates 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 reworked.
• For route-based Any-to-Any, manual firewall rules and routes are planned.
• NAT is either excluded or deliberately documented.
• Device Access for IPsec has been checked.
• Maintenance window, peer and fallback path are known.

After the change:

• Tunnel status is established.
• Log Viewer shows the expected firewall rule.
• Packet Capture shows outbound and return direction.
• Internal DNS and application access were tested.
• Byte counters increase in both directions.
• NAT and return path are aligned with the peer.
• The change is recorded in the network documentation.

Frequently asked questions