Skip to content
Avanet

Sophos Firewall IPsec VPN Troubleshooting

Sophos Firewall

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.

Diagnostic path

  1. Tunnel remains down: Check the IKE version, IPsec profile, gateway, Local/Remote ID, PSK, or certificate in strongswan.log.
  2. Phase 1 is up, but there is no Child SA: Compare traffic selectors, the Phase 2 proposal, PFS, and subnets.
  3. Tunnel is green: Use ipsec statusall to verify that the SA is ESTABLISHED, the Child SA is INSTALLED, and the byte counters increase.
  4. Only one direction counts bytes: Check firewall rules, NAT, routing, and especially the return path on the remote side.
  5. The cause remains unclear: Trace a single test flow with Log Viewer and Packet Capture.
  6. The firewall repeatedly crashes with multicast over VPN: Do not provoke the issue with further load tests. Record the firmware version, timestamps, and available diagnostic data; NC-180433 is fixed in SFOS 22.0 MR2 Build 546.

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.

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 insufficient, first check the current state in the Advanced Shell:

service -S | grep strongswan

If it already shows RUNNING,DEBUG, do not run the toggle again as if enabling debug. Use the existing debug state and then disable it as described below.

⚠️ Enable debug only briefly. It can quickly generate large log files and consume storage space.

If debug is not yet active, run the toggle, check the new state, and reproduce the error exactly once:

service strongswan:debug -ds nosync
service -S | grep strongswan
tail -f /log/strongswan.log

For strongswan, the state should show RUNNING,DEBUG. Afterwards, the same command disables debug mode again; the second command confirms that it has returned to the normal state:

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. Reset the PSK on both sides; invisible spaces or copying and pasting from password managers are common causes. An incorrect ID can prevent peer assignment before the expected PSK is even 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 remain empty, 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:

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

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

With policy-based IPsec, SFOS 22 manages the VPN routes in the backend. Manual IPsec routes and route precedence are checked in the Device Console:

system ipsec_route show
system route_precedence show

The command familiar from older troubleshooting procedures in the Advanced Shell is not reliable evidence for a policy-based tunnel under SFOS 22:

ip route show table 220

Under SFOS 22, policy-based VPN routes and manual ipsec_route entries are not visible there. A missing entry therefore proves neither a missing route nor a routing error.

With route-based IPsec, a static, SD-WAN, or dynamic route to the XFRM interface and matching XFRM states must exist. 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 the XFRM states in the Advanced Shell:

ip xfrm state
ip xfrm policy

XFRM interfaces must not use overlapping transfer networks. Connections with identical local and remote subnets belong in a common IPsec failover group or require clearly different selector and routing logic. The linked procedure explains group order, the Health Check, and the controlled failover test.

Check NAT by tunnel type

NAT is allowed, but it must match the tunnel type and the addresses expected by the remote side.

  • 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: MASQ translates the source to the XFRM IP; this is visible in the inner IP header in Packet Capture.
  • Route-based with specific traffic selectors: If a MASQ rule matches, the firewall drops the traffic because such XFRM interfaces have no assigned IP address.

The original and translated source must be documented, permitted on the remote side, and routed back. NAT on Sophos Firewall explains the basics 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.
  • Multiple connections with the same subnets are not in the same failover group.
  • 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 Build 411 or MR1 Build 490 on certain physical 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 original state:

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:

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

Disable StrongSwan debug afterwards. 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.