Sophos Firewall: Systematically diagnose an IPsec VPN

The order of checks matters when troubleshooting IPsec: first verify IKE and the Child SA, then firewall rules, NAT, routing, and the return path. A green tunnel only confirms the negotiation—not that user traffic works.

For a new tunnel, start with Set up a Sophos Firewall site-to-site IPsec VPN. The following steps apply to an already configured connection.

Don’t change global advanced settings such as session cleanup on failover, the anti-replay window, the IKEv2 cookie threshold, or the use of already resolved peer addresses as a first diagnostic attempt. Use global VPN settings safely explains their effect, baseline check, and rollback.

Diagnostic path

Tunnel remains down: Check the IKE version, IPsec profile, gateway, Local/Remote ID, PSK, or certificate in strongswan.log.
Phase 1 is up, but there is no Child SA: Compare traffic selectors, the Phase 2 proposal, PFS, and subnets.
Tunnel is green: Use ipsec statusall to verify that the SA is ESTABLISHED, the Child SA is INSTALLED, and the byte counters increase.
Only one direction counts bytes: Check firewall rules, NAT, routing, and especially the return path on the remote side.
The cause remains unclear: Trace a single test flow with Log Viewer and Packet Capture.

Only a few documented values are needed first: tunnel name, peer IP or FQDN, IKE version, Local/Remote ID, local and remote networks, policy-based or route-based, IPsec profile, and one test with source, destination, and service. Example: tunnel azure-vpn, local 172.16.10.0/24, remote 10.20.30.0/24.

With policy-based IPsec, the networks are part of the negotiation. Route-based IPsec uses an XFRM interface and static, SD-WAN, or dynamic routes. If the path is incorrect, see the separate guides to IPsec routes and route precedence.

⚠️ Logs and packet captures can contain public IP addresses, internal networks, hostnames, or user data. Collect them selectively and for a limited time, and review them before sharing.

Before using the CLI, Current activities > IPsec connections shows only the IPsec connections that are currently established. You can filter the list by Connection name, Local server name, Local subnet, Username, Remote server/host, or Remote subnet and reload it with Refresh. Disconnect actively terminates the selected connection and isn’t a harmless refresh: document the time and state first, then disconnect only in a planned test window. This snapshot doesn’t replace Child SA, log, or traffic validation.

Check logs and the CLI

Under Site-to-site VPN > IPsec, Show additional properties displays the Local subnet, Remote subnet, Gateway type, and Profile, among other values. Under Profiles > IPsec profiles, the Phase 1 and Phase 2 values can also be compared directly.

The most important files in /log are:

strongswan.log: IKE, authentication, and Child SAs
charon.log: IKE daemon
ipsec_monitor.log: IPsec service monitoring
/log/ipsec_conn/ipsec_<connectionname>.log: Connect, Activate, and Deactivate actions in WebAdmin
xfrmi.log: XFRM interfaces
dgd.log: Dead Gateway Detection and VPN failover

The current central SFOS 22 log list names ipsec_monitor.log. An older Sophos troubleshooting page still lists strongswan-monitor.log; for current SFOS 22 systems, the newer log list is authoritative.

In the Advanced Shell, the main log can be followed live or filtered. If SSH and shell access are unfamiliar, see Sophos Firewall CLI troubleshooting: important commands.

cd /log
tail -f /log/strongswan.log
tail -f /log/strongswan.log | grep -i azure-vpn
less /log/strongswan.log
grep -i "no proposal" /log/strongswan.log

These lines are alternatives, not a continuous procedure. In less, use /searchterm to search within the file.

StrongSwan debug

If the normal log is not sufficient, record the current state in the Advanced Shell first:

service -S | grep strongswan

If the output already indicates an active debug state, do not run the toggle command again. First identify who enabled it and why; the sequence below applies only when debug was initially inactive. The exact status text can vary by build.

⚠️ Run debug only briefly. It can quickly create large log files and consume storage.

If debug is not active, run the command once and check the new state:

service strongswan:debug -ds nosync
service -S | grep strongswan

Then follow strongswan.log in a second terminal, reproduce the issue exactly once, and stop tail with Ctrl+C:

tail -f /log/strongswan.log

Finally, run the same toggle command once. The second line must confirm that the previously recorded normal state without debug has been restored:

service strongswan:debug -ds nosync
service -S | grep strongswan

Check tunnel establishment

Phase 1: IKE, IDs, and authentication

If the tunnel does not come up, the IKE version, gateway, IDs, proposal, PSK, or certificate usually do not match.

no IKE config found or Remote peer is refusing our Phase 1 proposals: The firewall cannot find a matching connection or the profile does not match. Check the IKE version, Listening Interface, peer address, Local/Remote ID, and profile.
peer authentication failed, AUTH_FAILED, AUTHENTICATION_FAILED, no matching peer config found, or Remote peer reports we failed to authenticate: The IDs and authentication do not match the expected peer configuration.
invalid HASH_V1 payload length or decryption failed: With IKEv1, this often means an incorrect PSK; with IKEv2, AUTH_FAILED is more common.
The remote side reaches a different public address, or UDP 500/4500 is not forwarded correctly by NAT, a router, or the provider.
With certificates, the certificate chain, issuing CA, validity, or expected ID does not match.

If a certificate was revoked before expiry or the effect of revocation remains unclear, verify the issuer, serial number, thisUpdate, nextUpdate, and service-specific rejection together. Import and test Certificate Revocation Lists on Sophos Firewall shows the safe procedure.

The local ID on one side must match the remote ID on the other, and vice versa. Compare the IDs and stored PSK on both sides first. If the PSK must be reset, coordinate the change on both peers in a maintenance window; invisible spaces and copy-and-paste from password managers are common causes. A wrong ID can prevent peer matching before the expected PSK is checked.

Phase 2: Traffic selectors and Child SA

If Phase 1 is up but there is no Child SA, the subnets or Phase 2 values usually differ.

traffic selectors ... inacceptable
failed to establish CHILD_SA
received traffic selectors didn't match
Remote peer reports INVALID_ID_INFORMATION
differing values for TSi and TSr
NO_PROPOSAL_CHOSEN after Phase 1 is up and Initiating establishment of Phase 2 SA

NO_PROPOSAL_CHOSEN alone is not enough to classify the problem: before Phase 1, it indicates IKE/Phase 1 values; after a successful Phase 1, it indicates ESP, PFS, or other Phase 2 values.

For a complete comparison of General settings, Phase 1, Phase 2, and DPD fields, see Understand and securely configure Sophos Firewall IPsec profiles.

The networks must be mirrored. If Sophos expects local 172.16.10.0/24 and remote 10.20.30.0/24, the remote side must offer 10.20.30.0/24 to 172.16.10.0/24. A /24 on one side and a single host on the other, or inconsistent host objects, can also prevent the Child SA.

Tunnel is up, but no traffic flows

In the Advanced Shell, this command displays SAs, negotiated networks, and byte counters:

ipsec statusall

The important values are ESTABLISHED, INSTALLED, and the counters in both directions. If both stay at zero or do not increase, the test traffic probably does not reach the tunnel. If only the outbound side increases, the return path or a rule on the remote side is usually missing; if only inbound bytes increase, suspect the local route, local rule, or target system.

Trace a test flow

A narrowly defined test is more informative than several simultaneous pings:

Source IP: 172.16.10.25
Destination IP: 10.20.30.15
Service: ICMP or TCP 443
expected direction: LAN to VPN
expected rule: LAN_to_VPN_Branch

Then check in this order:

Enable Log firewall traffic in the affected rule.
Filter Log Viewer by source, destination, and Rule ID.
Start Packet Capture with host 172.16.10.25 and host 10.20.30.15.
Run the test exactly once.
Compare the rule, NAT Rule ID, forwarding, response, and byte counters.
Check the return route, remote rule, and target system on the remote side.

Packet Capture uses a limited buffer and stops when it is full. The view shows fields including Rule ID, NAT ID, Status, and Reason. During a standard capture, accelerated FastPath traffic is normally sent through SlowPath temporarily. Check buffer state, filter, and test timing before treating an empty or stopped capture as proof that no traffic exists.

If no packet reaches Sophos Firewall, the cause is upstream, such as the client gateway, VLAN, or local routing. If a packet arrives but is not forwarded, the rule, NAT, route, or a security feature does not match. The complete rule test is described under Test a firewall rule with Log Viewer, Policy Test, and Packet Capture.

Routing and XFRM

For policy-based IPsec, SFOS creates VPN routes in the backend. They do not appear in the normal routing view. Read manual IPsec routes and route precedence in the Device Console:

system ipsec_route show
system route_precedence show

The default order is static, sdwan_policyroute, vpn. A missing entry in the normal routing view therefore does not prove a routing fault. For the specific test flow, correlate Diagnostics > Tools > Route lookup, the firewall log, and Packet Capture.

For route-based IPsec, the routing path depends on the XFRM interface type:

Any/Any or Dual: The XFRM interface has IP addresses. A static, SD-WAN, or dynamic route must direct remote traffic to it.
Specific traffic selectors: SFOS creates the static route automatically. You cannot assign an IP address or an additional route to the XFRM interface.

Check the XFRM interface under Network > Interfaces and the path under Diagnostics > Tools > Route lookup. The Device Console shows configured static routes:

show static-route

Check XFRM states in the Advanced Shell:

ip xfrm state
ip xfrm policy

If several connections use the same local and remote networks as alternative paths, their selection and failover design must be explicit. Put policy-based connections and route-based connections with specific traffic selectors in the same IPsec failover group. Any/Any XFRM tunnels can instead fail over through SD-WAN routes; the linked procedure explains group order, health checks, and a controlled switchover test.

Check NAT by tunnel type

NAT is allowed, but it does not replace a route. First make sure the original or translated destination path selects the correct tunnel; then verify that the remote side expects the addresses actually used.

If local and remote networks are identical, a single SNAT note is not enough. Use NAT for overlapping IPsec networks provides the complete mirrored addressing, tunnel, rule, and routing procedure.

Policy-based with SNAT: The intended SNAT rule requires Outbound interface Any. The default SNAT rule with specific WAN ports does not match policy-based IPsec traffic.
Route-based with Any/Any or Dual: The XFRM interface has an IP address and needs an explicit route. Determine whether and how translation occurs from the matching NAT rule and Packet Capture; do not infer translation from the tunnel type alone.
Route-based with specific traffic selectors: SFOS creates the route automatically and does not assign an IP address to the XFRM interface. Assuming MASQ to a supposed XFRM IP is therefore not a reliable diagnostic path; inspect the original and translated source and the matching NAT Rule ID instead.

Document the original and translated source, allow both as required on the remote side, and provide the return route. NAT on Sophos Firewall explains the fundamentals and rule order.

Instability and SFOS 22 special cases

If traffic stops later, compare timestamps in the tunnel status, strongswan.log, dgd.log, WAN events, and application test. Common causes are:

The third-party device uses traffic-based rekeying; Sophos Firewall supports time-based rekeying.
Both sides rekey simultaneously. Deliberately stagger the Phase 1 and Phase 2 key lifetimes of the initiator and responder.
The assigned interface was disabled. Initiating tunnels disconnect immediately; responders disconnect no later than after inactivity or the DPD timeout.
Large transfers fail even though a small test works; in this case, check MTU and MSS.

Repeated firewall crashes with multicast over VPN

If the crashes coincide with multicast traffic passing through a VPN tunnel, first record the firmware version and build, affected tunnel, timestamps, and available diagnostic or crash data. Sophos confirms this issue as NC-180433 and fixed it in SFOS 22.0 MR2 Build 546.

The public issue description does not identify a specific tunnel type or multicast design and does not provide a CLI workaround. On an older SFOS 22 build, check the upgrade path, update to MR2 Build 546 or a newer approved version, and then retest the same traffic under controlled conditions. Do not change tunnel parameters, IPsec Acceleration, or services based on assumptions. If the firewall still crashes on MR2 or later, provide the collected data to Sophos Support instead of automatically continuing to attribute the problem to NC-180433.

The normal setup and controlled validation are explained in Multicast Routing on Sophos Firewall; the crash described here remains a firmware-specific exception.

IKEv2 packets are fragmented

With known issue NC-136352, the default IKEv2 profile can offer so many DH groups that IKE packets exceed 1'500 bytes. If an intermediate component drops fragments or PMTU information, the initiator sends repeatedly while the responder sees nothing.

For this exact symptom, check the peer in the Advanced Shell:

tcpdump -ni any 'host 203.0.113.10 and (udp port 500 or udp port 4500)'

Then configure only the required DH group, or significantly fewer groups, in the IPsec profile. Sophos Firewall tcpdump describes general tcpdump filters and PCAP export.

PPPoE alias and IPsec acceleration

NC-181526 affects SFOS 22.0 GA Respin Build 411 or MR1 on certain XGS Appliances: the tunnel uses an alias interface of a PPPoE WAN port, is connected, but carries no user traffic while IPsec acceleration is active. XGS 88/88w, 108/108w, 118/118w, and 128/128w are excluded.

The current Sophos Known Issues List names SFOS 22.0.2 MR2 Build 546 as the fixed version; however, NC-181526 does not appear separately in the published MR2 fix list. Therefore, repeat the same test flow after the update instead of inferring the fix from the version alone.

⚠️ Disabling IPsec acceleration is global, restarts all IPsec tunnels, and causes an interruption. Test it in a maintenance window only when the combination of build, hardware, PPPoE alias, and symptoms matches exactly.

Run the following commands in the Device Console:

system ipsec-acceleration show
system ipsec-acceleration disable
system ipsec-acceleration show

If there is no improvement, restore the previously recorded state. If acceleration was enabled before the test, use:

system ipsec-acceleration enable

With NC-180520, SFOS 22.0 MR2 fixes a similar but different alias IP case: the XFRM gateway could remain unreachable with acceleration active when ESP arrived through another WAN port. The two issue IDs must not be treated as identical. The SFOS 22 upgrade check covers further checks before and after the update.

Acceptance and escalation

After every change, repeat the same single test flow and document at least these points:

Time, tunnel name, peer IP, source, destination, and service
WebAdmin status and ipsec statusall before and after the test
Assigned firewall and NAT rule
Packet Capture and counters in both directions
Return route and remote rule on the remote side
Change, result, and prepared rollback

Only disable StrongSwan debug afterwards if you enabled it during this procedure. Do not change a pre-existing debug state until its owner and purpose are clear. Save only the logs relevant to Sophos Support; Save Sophos Firewall logs describes the export. Check larger log packages and captures for sensitive data before sharing.