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.

For the IDs in this example, set Local ID type = DNS and Remote ID type = DNS on both firewalls. At the head office, enter Local ID vpn-hq.example.invalid and Remote ID vpn-branch.example.invalid; at the branch, reverse these values exactly. These values identify the peers; they are not used to resolve their gateway addresses via DNS. If a different ID type is used, the type and format must also match crosswise.

For each IPv4 network object, select Add, IP version = IPv4, and Type = Network, enter the network address and /24 subnet mask, then save. Suitable names are HQ_LAN for 10.10.10.0/24 and Branch_LAN for 10.20.20.0/24; both objects are needed on both firewalls. A host object, by contrast, represents a single test or monitoring address.

Using the branch as the initiator distributes connection retries across the branches and is appropriate when the branch WAN IP changes. If an initiator needs to reach a peer with a dynamic WAN IP, that peer’s Gateway address must contain a DNS hostname that actually resolves to its current public address. Set up and verify Dynamic DNS on Sophos Firewall covers registration and resolution testing. A DNS ID alone is not a reachable gateway address. DDNS configured only at the head office does not make the dynamic branch address discoverable.

⚠️ 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. In the worked example, the head office router’s WAN address could be 198.51.100.10, while the firewall WAN uses 172.31.255.2. The head office then selects its private WAN as the Listening interface; the branch still connects to 198.51.100.10, not to 172.31.255.2. The router translates the destination from its public address to 172.31.255.2. The LAN selectors remain Local 10.10.10.0/24 and Remote 10.20.20.0/24 at the head office, with exactly the reverse at the branch.

For NAT-T, UDP 500 and UDP 4500 must be allowed. The SFOS 22 and SFOS 23 procedures for a firewall behind a router also list IP protocol 50, not TCP/UDP port 50. When NAT-T is negotiated, ESP is carried inside UDP 4500; native ESP uses protocol 50. The router requirements and the NAT-T explanation must therefore not be treated as descriptions of identical packet paths. Before the change, document the router’s capabilities and existing forwarding configuration, then use IKE logs and Packet Capture to verify which path is actually used. Do not remove an existing ESP allowance without checking it; restrict additional allowances to the planned peer addresses. If negotiation fails, restore the documented router configuration. This is separate from SNAT/DNAT for overlapping LANs 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. Local certificate belongs to the local firewall, Remote certificate belongs to the peer, and Remote CA certificate provides the trust anchor for the peer’s certificate. Do not use a public CA as the Remote CA certificate: an attacker with a valid certificate from that CA could otherwise gain unauthorised access. With the ID type DER.ASN1 DN (X.509), the Distinguished Name of the respective certificate is used; enter the DN of the peer’s certificate as the Remote ID.

RSA key is a separate Authentication type, not a selection of an RSA certificate. The firewall generates the key pair automatically and displays only the public key under Local RSA key. Copy this into Remote RSA key on the peer, and paste the peer’s public key into the local Remote RSA key field. Both sides must use the same PKCS1 or DNS format. Private keys are not transferred between the firewalls.

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

For this policy-based example, select specific networks on both sides. The SFOS 22 and SFOS 23 documentation is not consistent in its wording about Any: the Policy-based overview says that Any cannot be selected for local and remote subnets, whereas the Add an IPsec connection procedure allows Any on no more than one side. Do not infer support for an Any-to-Any policy-based configuration from this. If Any is required on one side, check the option in the installed build, the peer’s selectors and the intended routing in an isolated test configuration before implementation. If unexpected SAs or traffic assignments occur, deactivate the new connection and restore the documented specific selectors. With multiple specific local and remote networks, one Phase 2 SA is created per combination: two local and two remote networks produce four SAs. All policy-based connections share one IPsec interface, so a capture on that interface alone does not identify the tunnel.

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.

With Authentication type = Preshared key, enter the agreed PSK and repeat it in the confirmation field. Enter exactly the same PSK on the peer and confirm it there as well; the mirrored IDs do not change the shared key. Exchange the PSK only through the designated secure channel, and do not include it in screenshots or public tickets.

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.

Without Activate on save, activate the saved connection using its Status button under Site-to-site VPN > IPsec. This is distinct from Gateway type = Disable: the connection remains inactive until initiated by the user. Respond only waits for requests; Initiate the connection starts negotiation, including after the VPN service or firewall restarts. After Disconnect alone, an initiator can reconnect; rollback therefore also requires deactivating the connection.

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.

XML API: separate configuration from control actions

To automate this procedure, do not simply translate GUI fields into an XML request. The SFOS 22 and SFOS 23 API reference shows settings under VPNIPSecConnection/Configuration, alongside the control branches Active, DeActive, Connection and DisConnection, each containing Name. The sample comment says these four branches work only after the connection has been created. Separately, the configuration sample contains Status with Active/Deactive; the ActivateOnSave parameter row lists y/n. Saving, activation, behavior after a restart and an actually established tunnel are therefore not interchangeable settings or evidence of an executable API request.

The older representation also contains conflicts between the sample and parameter rows:

• In the sample, AliasLocalWANPort follows a comment for an alias WAN port, but the table lists it as a mandatory ARRAY. Name and RemoteHost are also listed as ARRAY; this establishes neither a safe multi-value serialization nor pairwise assignment of values.
• The UserAuthenticationMode sample shows AsServer/AsClient, while the row lists EnableAsServer/EnableAsClient. For DisconnectOnIdleInterval, the default 0 is outside the stated range 120..21600; 600 is only the sample value. Do not silently reconcile these values or adopt them as IKEv2 defaults.
• The older AllowNATTraversal field with Enable/Disable does not establish a current NAT-T switch. The RemoteHost row prohibits * with RSAKey; this is a restriction in that reference, not a general GUI runtime rule confirmed here.

Until the installed build’s API representation is clear, use the WebAdmin procedure above and resolve the ambiguities before automating it. The note does not supply a complete XML request; automatic NAT-T detection and the IKEv2, RSA and ID guidance remain unchanged for the GUI procedure described.

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. The SFOS 22 and SFOS 23 procedures also describe a generated XFRM interface for specific Traffic Selectors; unlike Any-to-Any, this interface must not receive an IP address or a manually assigned route. Before migration, document the installed SFOS version, the interface assignment and the route actually generated.

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 determine 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, also create a Custom Gateway with the peer’s XFRM IP address and use it in an SD-WAN Route.

For the SD-WAN alternative, select IPv4 and Add under Routing > SD-WAN routes. At the head office, set Source networks = HQ_LAN, Destination networks = Branch_LAN, and select Primary and backup gateways under Link selection settings. Under Primary gateway > Add, set Gateway IP to 10.255.0.2 and Interface to the local XFRM interface with 10.255.0.1/30. At the branch, reverse Source/Destination, use Gateway IP 10.255.0.1, and select the local XFRM interface with 10.255.0.2/30. For Health check, select an internal peer host that actually responds under Monitoring condition, for example 10.20.20.15 at the branch or 10.10.10.25 at the head office. The probe itself must be allowed and must use the intended tunnel. For SLA-based selection, select an SD-WAN profile containing the tunnel gateways. The static route and SD-WAN route are alternatives here; do not create both as competing paths without checking their interaction. Document the existing Route Precedence and rules before the change, and restore the previous route/gateway selection during rollback.

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

For specific subnets, the SFOS 22 and SFOS 23 procedures reviewed describe one XFRM interface per IPsec configuration. Under Network > Interfaces, expand the Listening interface using the blue indicator. Do not assign an IP address or a manual route to the generated interface: the static route is created automatically when the tunnel is established. At the head office, select Local HQ_LAN and Remote Branch_LAN; at the branch, select Local Branch_LAN and Remote HQ_LAN. Mirror the gateway, profile, authentication and IDs as for the other variants. For route-based connections, Any on only one side with a specific selector on the other is not supported. If the documented interface is missing from the installed build, first investigate the configuration, version and logs; do not try to force a replacement XFRM interface or Any-to-Any addressing.

This variant is suitable for small, clearly defined networks; Sophos recommends it over policy-based VPN, including for suitable third-party connections. Use the XFRM interface under Diagnostics > Packet capture to identify the outgoing traffic; also check the automatic route, every expected Child SA, logs and traffic in both directions. WAF over route-based IPsec with Traffic Selectors is not supported; a suitable Any-to-Any route-based configuration is an option for this. If a migration fails, deactivate the new connection and only its new rules, then reactivate the documented previous connection.

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.

The generated rules belong to the Automatic VPN rules group. In this example, the head office’s outgoing rule allows Source zone LAN, Source network HQ_LAN, Destination zone VPN, and Destination network Branch_LAN; reverse the zones and networks for the incoming rule. Apply the same mirrored configuration at the branch, with Branch_LAN as the local network. Restrict Services in each rule to the approved application ports and enable Log firewall traffic. Suitable existing rules can be extended with the correct Source/Destination networks instead of creating new rules for every tunnel. First check the impact on all other connections covered by that rule. SFOS evaluates rules from top to bottom and stops at the first match; a new rule at the top of the list can therefore override existing restrictions.

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

For NAT within the IPsec connection, enable Network Address Translation (NAT). Translated subnet shows the local translated network selected in the connection; under Original subnet, select the actual overlapping local network. Leave Not translated selected for networks without translation. Before saving, compare the original network, translated network, peer’s Remote selector and DNS destination address in a table. Do not infer the direction from the field names alone; the linked NAT procedure contains the complete example. For Any-to-Any, do not use these fields as a substitute for separate SNAT/DNAT rules.

⚠️ 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 not a standard step, but may be relevant for certain forwarded traffic scenarios. For system-generated authentication requests, the Sophos help texts for SFOS 22 and SFOS 23 contradict each other: the Routing/NAT overview states that this traffic does not require the command; the authentication procedure, however, describes a policy-based exception when the selected Route Precedence does not send the traffic into the tunnel. This implies neither an additional route for all system traffic nor a blanket change to the global Route Precedence.

Before any change, the source address, sys-traffic-nat, Traffic Selectors and return path must match the packet flow actually observed. The existing IPsec route guide and the procedure for system-generated authentication requests explain the targeted checks using a real request and Packet Capture, as well as separate rollback steps for NAT and the route. If the behaviour on the installed build remains unclear, it must be clarified with Sophos Support before making a production change. 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.

If a peer needs to ping the firewall itself through the tunnel, allow the VPN zone under Ping/Ping6 and select Apply. This is not a necessary global step for pinging a LAN host: the relevant transit rules and the host firewall determine that access. Enable only the local service access needed for the test, document its original setting, and restore it after the test unless it is required permanently. A ping from the firewall shell also uses a different source address from a LAN client; do not treat the two tests as equivalent checks of the client rule.

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.

Only connections that are actually established are displayed under Current activities > IPsec connections. The filters are Connection name, Local server name, Local subnet, Username, Remote server/host and Remote subnet; Refresh updates the display. 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.

For the worked example, test an actual branch host at 10.20.20.15 from the LAN client 10.10.10.25, not the network address 10.20.20.0. On Windows, ping 10.20.20.15 -t starts a continuous test; stop it with Ctrl+C. Under Diagnostics > Packet capture > Configure, set BPF string to host 10.10.10.25 and host 10.20.20.15 and proto ICMP, save, and enable capture. For route-based connections, check the outgoing traffic on the associated XFRM interface and the return packets. In Log viewer, search for the actual client address; use the Firewall rule ID and Filter firewall rule to open the matching rule. Then also test a planned application port and the opposite direction. Switch capture off again and remove temporary filters and access allowances; a continuous capture is not operational monitoring. When a router is in the path, also check both peers’ logs to confirm that NAT was detected and NAT-T negotiated.

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 the documented XFRM interface under the Listening interface, the automatic route, every expected Child SA, Selectors, VPN-zone rules and any MASQ rule. Use the XFRM interface for Packet Capture, but do not assign an IP address or manual route to it. If it is missing, investigate the build and configuration rather than creating a replacement interface.
• 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.

Remove a specific saved connection

Deleting a saved IPsec connection is different from Disconnect, deactivation or deleting a failover group. Before a separately approved removal, record the exact existing Name, Object Usage, group memberships and management access that does not depend on the tunnel. Do not delete a connection while it belongs to a failover group; the linked failover procedure covers controlled unassignment.

The SFOS 22 and SFOS 23 XML API deletion reference lists Name as a mandatory ARRAY with datatype STRING: first character A-Za-z, subsequent characters A-Za-z0-9_, maximum 100 characters, multiple values allowed. However, it contains no request sample. Infer neither a multi-name serializer nor a target name from the GUI example branch-zurich; do not rewrite a saved name to make it appear compliant.

The reference maps XML operation status 200 to Message.IPSecDeleteSuccess, 201 to Message.IPSecConnInUse and 500 to Message.IPSecDeleteFail. Message text is inserted through JavaScript and is not resolved here: these are neither HTTP status codes nor confirmed displayed response texts. Do not count 201 as successful deletion merely because the number starts with 2; for Edit, the same number maps to Message.IPSecUpdated. After an approved removal, read back exactly that target and check the remaining production paths. If the result is unclear, investigate the target state and dependencies before retrying, rather than repeating blindly.

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