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 Fusion (formerly 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. Outside the Sophos interface, route-based is also often called tunnel-based. Both terms describe a tunnel with its own XFRM interface. The occasionally used term “root-based”, however, is not a VPN mode.

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.

What a green tunnel actually confirms

A status such as Established confirms that the peers have negotiated IKE and at least one Child SA. It does not confirm that a route is selected, the firewall rule matches, NAT is correct, the peer knows the return path, or the target host responds. A tunnel can therefore be green without carrying usable site traffic.

Sophos Firewall uses ESP in tunnel mode. ESP protects data integrity, authenticates the origin of payload data, and provides anti-replay protection against replayed packets.

The data path can be used as the following mental model:

Policy-based
Source -> Firewall rule -> Local/Remote selector -> Child SA -> Peer -> Return route and rule -> Target

Route-based Any-to-Any
Source -> Route or SD-WAN route -> Firewall rule -> XFRM -> Child SA -> Peer -> Return route and rule -> Target

This is a diagnostic model, not a complete representation of the internal SFOS processing order. The distinction is nevertheless essential for acceptance testing: with policy-based VPN, the network pair in the IPsec connection determines which traffic belongs to the tunnel. With route-based Any-to-Any, the routing or SD-WAN decision makes that selection.

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.

Consistent example for both firewalls

The following documentation values make the subsequent steps easy to follow. Replace all of them with your own WAN addresses, networks, and names:

First create both LAN networks as network objects under Hosts and services > IP host. At the head office, 10.10.10.0/24 is the Local subnet and 10.20.20.0/24 the Remote subnet; reverse these values at the branch. The same applies to the IDs: one side’s Local ID must be expected as the Remote ID by its peer. The transfer network 10.255.0.0/30 is used only for route-based Any-to-Any and must not overlap with any production, VPN, or management network.

⚠️ 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.

⚠️ With IKEv1, the firewall uses the PSK from the most recently configured connection for the same local and remote gateway combination. This applies to site-to-site and remote-access IPsec configurations. Configuring a later connection for that gateway combination with a different PSK can cause existing connections to fail authentication during a subsequent negotiation. Before adding such a connection or changing a PSK, check all affected IKEv1 configurations and align the PSK with their respective peers before the next negotiation.

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.

Sophos Firewall does not provide a separate NAT-T switch: The devices detect NAT automatically. Without NAT, IKE negotiations use UDP 500, while payload traffic uses ESP over IP protocol 50. When the firewall detects a NAT device, it encapsulates subsequent IKE and phase 2 negotiations as well as ESP packets in UDP 4500.

If there is a NAT device on the IPsec path and the peer is a third-party firewall, NAT-T must also be enabled there. Check the setting against that peer’s documentation; Sophos Firewall does not need an additional switch.

The peers detect a NAT device during the phase 1 IKE exchange and then agree to use NAT-T. ESP is a layer 3 protocol without layer 4 port information, whereas PAT can also translate ports. UDP encapsulation over port 4500 therefore gives the NAT path an identifiable UDP wrapper; the peer removes this wrapper and processes the original IPsec packet.

If Sophos Firewall itself is behind a router, that router needs DNAT or port forwarding from the public address to the firewall’s private Listening interface. The NAT-T path must allow UDP 500 and UDP 4500; native ESP over IP protocol 50 is only needed on a path without NAT. This is separate from the later SNAT or DNAT design for overlapping networks or translated payload traffic.

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.

When Digital certificate is selected, choosing it in the connection form is not sufficient. CA trust, local certificates, peer certificates, and Certificate IDs must be prepared in advance. The complete procedure is described in Set up certificate-based IPsec Site-to-Site. If the CA revokes certificates before they expire, the current revocation list must also be included in the operations plan. Importing a CRL, checking nextUpdate, and running a controlled negative test on Sophos Firewall are covered in a separate procedure.

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 Branch-Zurich-IKEv2. 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. Before activation, check Dead peer detection: Sophos specifies Hold or Disconnect for the responding peer and Re-initiate for the initiator. An IPsec failover group changes this behavior and does not follow the same DPD logic.

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.

Then create the connection on the peer with mirrored settings. In this example, the head office waits with Respond only for 203.0.113.20; its Local/Remote networks are 10.10.10.0/24 and 10.20.20.0/24, respectively. The branch uses Initiate the connection, gateway address 198.51.100.10, and reverses the Local/Remote networks and Local/Remote IDs. The profile, authentication, and PSK must be compatible. Activate the connection only after both entries have been saved and the rules checked.

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 from route selection. With Any-to-Any, SFOS provides a dedicated, addressable XFRM interface. For specific Traffic Selectors, current SFOS 22 documentation conflicts on interface creation, as explained below.

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

For Any-to-Any, Sophos shows the generated XFRM interface under the physical interface used in:

Network > Interfaces

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

Any-to-Any with IPv4, IPv6 or Dual

When both Local subnet and Remote subnet are set to Any, SFOS automatically creates the XFRM interface for the route-based IPsec connection. There is no separate XFRM interface to add. Under Network > Interfaces, expand the physical interface selected as the listening interface and open the generated XFRM interface. In this example, assign 10.255.0.1/30 to the head office and 10.255.0.2/30 to the branch. With Dual, separate IPv4 and IPv6 firewall rules are also required.

The editable Name is the display name. Do not confuse it with the values SFOS assigns to the interface: Hardware is the record name, IPsec connection is the associated route-based connection, and Network zone is always VPN. Configure only the address fields for the IP version selected in the IPsec connection:

• IPv4/netmask: enter the planned IPv4 transfer address and select its subnet.
• IPv6/prefix: enter the planned IPv6 transfer address and prefix.
• With Dual, configure both address families. If the connection is only IPv4 or only IPv6, SFOS doesn’t apply values entered for the other version.

Under Advanced settings > Interface settings, retain the default MTU or enter the deliberately tested value. SFOS calculates the default by subtracting the maximum IPsec overhead from the physical interface MTU. Enable Override MSS and enter a value only when the network requires a value other than the firewall default; don’t assume an undocumented numeric default.

Before changing these fields, record the current name, addresses, MTU, Override MSS state and value, and dependent routes or gateways. Save, reopen the interface, and verify that its assigned Hardware, IPsec connection and VPN zone are unchanged. Then use Route lookup on both peers and test real traffic in both directions, including a large transfer when MTU or MSS changed. To roll back, restore the recorded field values and previous routes or gateways. For a newly deployed connection, deactivate it and remove only its dependent routing and rules; don’t try to delete or recreate the generated XFRM interface independently.

Next, create the route to the remote LAN on both sides. For a simple static setup, open Routing > Static routes > IPv4 unicast route > Add:

• Head office: Destination 10.20.20.0/24, Interface the local XFRM interface.
• Branch: Destination 10.10.10.0/24, Interface the local XFRM interface.

Alternatively, use an SD-WAN Route or dynamic routing through BGP or OSPF. For an SD-WAN Route, decide explicitly whether a different path is allowed as a fallback. If traffic must not use another route when the tunnel is down, enable Route only through specified gateways and test this failure mode separately.

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 four 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. Diagnostics > Tools > Route lookup returns the expected XFRM interface or XFRM gateway for an actual host in the remote LAN. Run the same test on the peer.
4. Firewall rules permit only the planned directions and services.

Traffic Selectors

With specific subnets, SFOS 22 behavior in this edge case is not unambiguous: an XFRM interface may be absent, but the firewall can also create one per traffic-selector configuration. Expand the listening interface under Network > Interfaces and verify the actual state on the installed build; an existing XFRM interface can also be selected under Diagnostics > Packet capture. If an XFRM interface appears, don’t assign an IP address or routes to it. The static route is created automatically when the tunnel is established. Any on only one side with a specific selector on the other isn’t supported.

This variant is suitable for small, clearly defined networks. If the interface is visible, use it as documented to confirm outbound traffic in Diagnostics > Packet capture; also check the automatic route, Child SAs, logs, and traffic in both directions. 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.

Incoming IPsec packets are first decapsulated and decrypted. The matching firewall rule then applies its security policies to the payload traffic before it is forwarded to the destination. For outgoing traffic, the matching firewall rule applies before encapsulation and encryption.

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. NAT does not replace a route and does not change the routing decision: independently of translation, SFOS must be able to select a suitable VPN, static, SD-WAN, or dynamic route to the destination.

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, use the NAT setting in the IPsec connection and don’t assign an IP address or manual route to an XFRM interface if the installed build shows one. IPsec with NAT for overlapping networks shows the complete mirrored address, DNS, and NAT design.

If traffic from a route-based VPN with Traffic Selectors matches an SNAT rule with Translated source = MASQ, the firewall drops the packets because these XFRM interfaces have no assigned IP addresses. This can explain a green tunnel with no usable traffic. For the affected test flow, check the matching NAT rule and its order, and correct only the conflicting rule; don’t disable MASQ indiscriminately for other connections. Then retest the same flow in both directions with Log Viewer and Packet Capture.

If policy-based IPsec payload traffic is translated by a separate SNAT rule, its Outbound interface must be set to Any. A rule that lists only specific WAN ports there—normally including the default SNAT rule—does not match this VPN traffic. With Any, the firewall uses the Translated source configured in the matching SNAT rule. This behavior also applies when Override source translation (SNAT) is enabled for specific outbound interfaces.

Since SFOS 22, policy-based IPsec creates the VPN route in the backend. A manual ipsec_route is relevant only for certain forwarded traffic scenarios 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.

Under Current activities > IPsec connections, filter the connections that are actually established by Connection name, Local subnet, or Remote subnet, and update the view with Refresh. Disconnect terminates an existing SA in a controlled manner, for example once both sides are ready for a configuration change; it does not replace disabling or rolling back the connection.

Determine the expected number in advance: route-based Any-to-Any creates one Phase 2 connection per XFRM interface, while Dual creates one each for IPv4 and IPv6. Policy-based and route-based with Traffic Selectors create one connection for every combination of Local and Remote subnet.

Before sending the first payload traffic through route-based Any-to-Any, check the actual destination host address under Diagnostics > Tools > Route lookup. On each firewall, the result must point to the intended XFRM interface or XFRM gateway.

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: check whether the actual build shows the XFRM interface under the listening interface. If shown, use it in Packet Capture but don’t assign an IP address or route to it. Also 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.

Rollback after failed acceptance

Roll back a new tunnel in a controlled manner rather than deleting rules and objects speculatively:

1. Under Current activities > IPsec connections, terminate the affected SA with Disconnect and disable the new IPsec connection.
2. Disable only the static or SD-WAN routes, NAT rules, and firewall rules newly created for this change. This includes automatically generated VPN rules. Don’t delete a generated XFRM interface independently if the build shows one; disabling the connection manages that interface.
3. For a migration, reassign the previous profile to the old connection, then reactivate the connection and the old routing path.
4. Retest the original test flow and local Internet or site traffic with Log Viewer and Packet Capture.
5. Remove new objects only after Object Usage shows no further dependency and the old path has demonstrably resumed operation.

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 with Traffic Selectors, actual XFRM visibility has been recorded; no XFRM IP address or manual route is planned, whether or not the build shows the 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 has been completed and passed.
• 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