Sophos Firewall IPsec VPN Troubleshooting

IPsec site-to-site VPNs often operate quietly as long as they work. However, if a tunnel fails to establish, remains unstable after a reconnect, or shows as connected but does not transport traffic, a systematic approach to analysis is needed. Otherwise, you may find yourself jumping between PSK, routes, firewall rules, and logs without identifying the root cause.

This article explains how to systematically check IPsec connections on the Sophos Firewall: first the tunnel setup, then the negotiated networks, and finally the actual packet flow. If a new site-to-site tunnel is being planned or set up, start with Setting up Sophos Firewall Site-to-Site IPsec VPN. For general CLI basics, Sophos Firewall CLI Troubleshooting: Important Commands can also be helpful.

Before Troubleshooting

First, briefly document the initial situation. This may seem trivial, but it saves a lot of time because many IPsec problems arise from asymmetric assumptions: one side believes it is connecting network A to network B, while the other side expects different IDs, subnets, or an IKE version.

Key points:

• Tunnel name: azure-vpn
• Local gateway: WAN address or FQDN of the Sophos Firewall
• Remote gateway: public IP or FQDN of the peer
• IKE version: IKEv1 or IKEv2
• Authentication: Preshared Key or certificate
• Local ID / Remote ID: IP address, FQDN, or email-like identifier
• Local networks: 172.16.10.0/24
• Remote networks: 10.20.30.0/24
• VPN type: policy-based or route-based
• Gateway type: Initiate the connection, Respond only or failover group
• IPsec profile: Phase 1, Phase 2, DH groups, PFS and lifetimes
• Expected traffic: Source, Destination, Port, and Direction

In policy-based IPsec, the local and remote networks are part of the tunnel negotiation. In route-based IPsec, it is also important which routes point to the tunnel interface. If traffic runs in the wrong direction despite an active tunnel, IPsec Routes, static routes, SD-WAN policy routes, or the Route Precedence of the Sophos Firewall are often involved.

If the tunnel is up and small tests work, but larger transfers hang, you should also check MTU and MSS. The procedure for this is described in Checking MTU and MSS for VPN Problems on Sophos Firewall.

⚠️ Debug logs and packet captures can contain sensitive data, such as public IP addresses, internal networks, hostnames, or payload data. Such data should only be collected selectively and for a limited time and should be reviewed before sharing.

Diagnostic Path

A simple sequence helps in practice:

1. Does the tunnel come up? If not, first check IKE version, IPsec profile, IDs, PSK/certificate, NAT-T, and reachability of the peer.
2. Is Phase 2 established? If not, check traffic selectors, local and remote networks, PFS, and Phase 2 proposals.
3. Is a Security Association installed? If yes, check ipsec statusall and pay attention to byte counters.
4. Is traffic flowing through the tunnel? If not, check firewall rules, NAT, routing, route precedence, IPsec routes, and return path.
5. Are packets visible? If unclear, combine Log Viewer and Packet Capture.

A common misconception: A green tunnel status only proves that IPsec has been negotiated. It does not prove that the firewall rules are correct, that the routes are accurate, or that the peer knows the return path.

Before moving to the Advanced Shell, it is worth checking the WebAdmin lists:

• Under Site-to-site VPN > IPsec, Show additional properties can display extra columns such as Local subnet, Remote subnet, Gateway type or Profile.
• Under Profiles > IPsec profiles, additional properties can also be displayed to compare Phase 1 and Phase 2 values more quickly.

This is not as deep as a log, but it prevents basic mistakes: wrong profile, wrong gateway type, identical subnets in several tunnels or a tunnel that is not part of the expected failover group.

Which Layer is Affected?

Before diving into debug logs, you should roughly categorize the problem. This quickly clarifies whether to look at IKE, Phase 2, routing, or packet flow.

• Tunnel remains down: IKE, Gateway, IDs, PSK, Certificate, or Proposal Check strongswan.log live and compare Phase 1
• Tunnel constantly switches between up and down: Rekey, DPD, WAN stability, or Proposal Compare timestamps, DPD, lifetime, and WAN events
• Phase 1 is up, but no Child SA: Traffic selectors, Phase 2 proposal, or PFS Check local and remote networks mirror image
• Tunnel is green, but byte counters remain empty: Traffic does not reach the tunnel Check firewall rule, NAT, route, and client gateway
• Only outgoing bytes increase: Return path or peer is missing Check remote firewall, remote route, and target system
• Packet Capture shows packets without matching rule: Rule order, zone, or service does not match Compare Log Viewer, Policy Test, and Rule ID

This categorization does not replace a detailed analysis. However, it prevents searching for a Phase 2 error in firewall rules or unnecessarily resetting the preshared key for a return path problem.

Collecting Logs

Sophos Firewall uses StrongSwan for IPsec. The main logs are located in /log:

• strongswan.log: Main IPsec log file for IKE, authentication, and Child SAs
• charon.log: Log of the IKE daemon, helpful depending on version and situation
• strongswan-monitor.log: Monitoring of the IPsec service
• dgd.log: Dead Gateway Detection and VPN failover

Access the Advanced Shell via SSH and switch to the log directory if needed:

cd /log

You can follow the live log directly:

tail -f /log/strongswan.log

If multiple tunnels are active, filtering is advisable. This can be done by tunnel name, a peer IP, or a typical error message:

tail -f /log/strongswan.log | grep -i azure-vpn

For existing log files, less is often more comfortable:

less /log/strongswan.log

In less, you can search within the file using /searchterm. Alternatively, grep filters directly:

grep -i "no proposal" /log/strongswan.log

Enabling StrongSwan Debug

If the normal log is insufficient, you can set the StrongSwan service to debug mode:

service strongswan:debug -ds nosync

Then check if the service is running in debug mode:

service -S | grep strongswan

The output should show RUNNING,DEBUG for strongswan. Then reconnect the tunnel or deliberately reproduce the error and monitor the log:

tail -f /log/strongswan.log

The same debug command disables debug mode again:

service strongswan:debug -ds nosync

⚠️ Only run debug as long as it is truly needed. IPsec debug can quickly generate large log files and unnecessarily consume storage space on the firewall.

Phase 1: IKE, IDs, and Authentication

If the tunnel does not establish at all, the cause is usually before or during Phase 1. At this stage, the gateways negotiate IKE, authentication, and the identities of both sides, not yet the user data networks.

Typical causes:

• IKE version mismatch
• IPsec profile or proposal mismatch
• Local or remote ID is different than expected
• Incorrect preshared key
• Peer reaches the wrong public IP
• NAT-T or port forwarding on UDP 500 and 4500 is not clean
• Certificates, CA, or validity do not match in certificate-based authentication

No IKE config found

A log entry like no IKE config found or NO_PROPOSAL_CHOSEN often means that the Sophos Firewall cannot find a matching IKE configuration for the incoming packet. This can be due to the IKE version, gateway, IDs, or IPsec profile.

Check:

• Is IKEv1 or IKEv2 set on both sides?
• Does the peer match the configured remote gateway address or FQDN?
• Do local and remote IDs match?
• Are encryption, authentication, DH group, and lifetime compatible?
• Is the peer using a different public IP than documented?

Peer authentication failed

peer authentication failed, AUTH_FAILED, or no matching peer config found often indicates mismatched IDs or authentication data. With preshared key, the key is often suspected first. This is often correct, but not always. If the ID does not match, the firewall may not even check against the expected peer configuration.

Check:

• Local ID on one side matches Remote ID on the other side.
• Remote ID on one side matches Local ID on the other side.
• Spelling, case sensitivity, FQDN, and IP addresses match exactly.
• Preshared key was entered without spaces at the beginning or end.
• With multiple tunnels to the same peer, it is clear which connection should match.

Invalid HASH_V1 payload or decryption failed

In IKEv1, messages like invalid HASH_V1 payload length or decryption failed often indicate an incorrect preshared key. In IKEv2, you are more likely to see AUTHENTICATION_FAILED or AUTH_FAILED.

In practice, you should reset the preshared key on both sides rather than just visually comparing it. Copy-paste from password managers, invisible spaces, or different special characters are classic time wasters.

Phase 2: Traffic Selectors and Security Associations

If Phase 1 is successful but Phase 2 does not establish, it usually involves the networks and the Child SA. The Sophos Firewall must negotiate with the peer which local and remote subnets are allowed through the tunnel.

Typical log hints:

• traffic selectors ... inacceptable
• failed to establish CHILD_SA
• received traffic selectors didn't match
• TSi and TSr show different networks than expected

Check:

• Local and remote networks are configured mirror image on both sides.
• Network mask and individual host objects match exactly.
• There are no unwanted overlaps with other tunnels.
• Multiple Phase 2 networks are represented the same on both sides.
• PFS, ESP encryption, authentication, and lifetime match.

Example: If the Sophos Firewall expects 172.16.10.0/24 locally and 10.20.30.0/24 remotely, the peer must offer exactly mirror image 10.20.30.0/24 to 172.16.10.0/24. A /24 on one side and a single host or a larger network on the other side can already prevent the Child SA from being installed.

Tunnel is Up, but No Traffic Flows

If the tunnel is shown as connected but no traffic passes through, IPsec itself is not automatically the cause. It usually involves routing, firewall rules, NAT, or the return path.

First, check the IPsec status in the Advanced Shell:

ipsec statusall

Key points of interest:

• Is the IKE SA ESTABLISHED?
• Is the Child SA INSTALLED?
• Which local and remote networks are displayed?
• Do the byte counters increase in both directions?
• Do you see only outgoing bytes but no incoming ones?
• Is it regularly reconnected or rekeyed?

For route-based IPsec, you can also check whether XFRM state and policy are installed at all:

ip xfrm state
ip xfrm policy

If ipsec statusall shows an established SA, but ip xfrm state or ip xfrm policy does not match the expected tunnel, the problem is often no longer PSK or proposal related. It is more likely to be traffic selectors, XFRM configuration, routes or competing tunnels.

If the Child SA is installed but the byte counters remain empty, the expected traffic likely does not reach the tunnel. Then check the path before and after IPsec.

Firewall Rules

Traffic through the tunnel requires appropriate firewall rules. Depending on the zone model, this might be LAN to VPN, VPN to LAN, or a separate zone. The rule must correctly cover source, destination, service, and direction.

Important:

• Enable Log firewall traffic in the relevant rules.
• Check rule position to ensure no more general rule applies first.
• Correctly choose source and destination zones.
• Avoid using overly broad objects in multiple VPNs if they could match the wrong tunnel.
• Deliberately check security features like IPS, web filter, or application control if they are active on the traffic.

A general testing procedure is described in Testing Firewall Rules with Log Viewer, Policy Test, and Packet Capture.

Routing and IPsec Routes

If the firewall does not send the traffic into the tunnel, check the routes. In policy-based IPsec, the IPsec routing table can also be relevant:

ip route show table 220

If manual assignment is necessary, an IPsec Route on the Sophos Firewall can help. If multiple routing types compete, you should also check the Routing Priority of the Sophos Firewall.

Check:

• Is there a more specific static route intercepting the traffic?
• Does an SD-WAN policy route apply before the VPN route?
• Does the client gateway really point to the Sophos Firewall?
• Does the peer have a return route to the local network?
• Are there overlapping local and remote networks?

For route-based VPN, also check the XFRM interfaces. Two XFRM interfaces must not be configured with overlapping or identical interface networks. If xfrm1 and xfrm2 are in the same transfer network, the tunnel can be established cleanly and still route incorrectly. In that case, check XFRM addressing under Network > Interfaces and use unique networks.

If several IPsec connections use the same local and remote subnets, they should not sit loosely next to each other. Such connections belong in a deliberate failover design or need clearly different selector or routing logic. Otherwise, the firewall cannot reliably use the intended tunnel.

NAT

NAT is not inherently wrong with IPsec, but it must be consciously configured. Unintended MASQ or an overly broad SNAT rule can cause the peer to no longer associate the traffic with the expected network.

Check:

• Does a generic MASQ rule apply before a specific VPN NAT rule?
• Does the peer expect original IP addresses or translated addresses?
• Is NAT documented on both sides?
• Does the NAT rule match the direction of the traffic?

If NAT is involved, the article Understanding NAT on Sophos Firewall: SNAT, DNAT, MASQ, PAT is helpful.

SFOS 22: Carefully Check Policy-based IPsec and NAT

When upgrading to SFOS 22, policy-based IPsec should be checked particularly carefully. Sophos notes in the SFOS-22 release notes a changed behaviour in policy-based IPsec VPN. Additionally, resolved issue NC-170917 is documented: Policy-based IPsec traffic could fail if the default SNAT rule was configured with a static IP address instead of MASQ.

In practice, this means: If a policy-based tunnel is green after the upgrade but no or only one-sided traffic flows, NAT should not be treated as a side issue. An old, broad, or unusually adjusted default SNAT rule can change exactly the traffic that the peer expects with the original networks.

Typical checkpoints after an SFOS-22 upgrade:

• Is the tunnel really policy-based?: In policy-based IPsec, local and remote networks are part of the negotiation. NAT can break this expectation.
• Was the default SNAT rule adjusted?: A static SNAT IP instead of MASQ can have different effects after an upgrade than expected.
• Are there specific VPN NAT rules?: These must be above general SNAT or MASQ rules and match the direction of the traffic.
• Do traffic selectors and NAT objects match?: The peer must expect either the original networks or the translated networks, not both randomly.
• Does Packet Capture show the expected source IP?: This reveals whether the firewall uses a different source address before the tunnel.

A clean test case consists of a source, a destination, and a service. Then check firewall rule, NAT rule, ipsec statusall, ip route show table 220, packet capture, and peer in sequence. If the test only works with a disabled or moved NAT rule, the problem is not with the tunnel setup but with the path into the tunnel.

For upgrade planning, Checking Sophos Firewall Before SFOS 22 Upgrade is also suitable. For NAT basics and rule order, Understanding NAT on Sophos Firewall is the better starting point.

Rekey, Failover and Interface State

If a tunnel works at first and fails later, the initial configuration is not always wrong. In that case, check the timeline:

• Traffic-based rekeying with third-party peers: Sophos Firewall expects time-based rekey logic. If the peer enforces traffic-based rekeying, the tunnel can hang or renegotiate after a while.
• Key exchange collisions: If both sides rekey at the same time, unstable phases can occur. In such cases, Phase 1 and Phase 2 lifetimes should be deliberately coordinated between initiator and responder.
• Interface disabled: If the associated interface is switched off, an initiating site-to-site tunnel disconnects immediately. Responder and remote access connections fail at the latest through inactivity or DPD timeout.
• DGD and failover group: In failover scenarios, also check dgd.log, gateway status, primary and secondary connection and identical subnet pairs.

These errors are easier to detect through timestamps than through a single snapshot. For intermittent problems, correlate tunnel status, strongswan.log, dgd.log, WAN events and application tests over time.

SFOS 22: PPPoE-WAN with Alias Interface and IPsec Acceleration

If after an upgrade to SFOS 22.0 GA or SFOS 22.0 MR1 an IPsec tunnel is connected but no traffic is forwarded, there may be an additional special case in certain setups. Sophos lists in the known issues NC-181526: On XGS hardware, IPsec tunnels on alias interfaces of a PPPoE-WAN port can be established but do not forward user traffic if IPsec acceleration is active.

This point should only be checked if the usual causes do not fit. A green tunnel without traffic is usually still a rule, routing, NAT, or return path problem. The SFOS-22 special case becomes more likely if all the following points coincide:

• Sophos Firewall runs on SFOS 22.0 GA or SFOS 22.0 MR1.
• It is XGS hardware.
• The affected tunnel uses an alias interface on a PPPoE-WAN port.
• The tunnel establishes, but user traffic is absent.
• Firewall rules, NAT, routes, return path, and packet capture do not explain the behaviour.
• IPsec acceleration is active.

As a workaround, disabling IPsec acceleration is documented:

system ipsec-acceleration off

This should not be used as a generic IPsec tuning command. The change should be made in a maintenance window or a documented support process, with before/after testing and clear attribution to the affected error pattern. Sophos lists SFOS 22.0.2 MR2 as the fix version for this known issue. When this version is released for the affected environment, a planned update is cleaner than a permanently forgotten workaround.

Practical testing procedure:

1. Document tunnel status and ipsec statusall.
2. Perform packet capture with a tight source/destination filter.
3. Check if the tunnel really uses an alias interface on a PPPoE-WAN port.
4. Note active SFOS version and hardware model.
5. Test changes to IPsec acceleration only deliberately and documented.
6. After the test, compare byte counters, packet capture, log viewer, and application test.

Combining Log Viewer and Packet Capture

The Log Viewer shows which rule or module evaluated a connection. Packet Capture in WebAdmin shows whether packets actually arrive, are forwarded, dropped, or processed by the firewall itself.

For IPsec troubleshooting, define a test as narrowly as possible:

• 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:

1. Enable logging in the firewall rule.
2. Filter Log Viewer by source IP, destination IP, and module Firewall.
3. Start packet capture with a tight filter, for example, host 172.16.10.25 and host 10.20.30.15.
4. Reproduce the test exactly once.
5. Check if packets arrive, are forwarded, and if responses return.

Interpretation:

• No packet arrives on the Sophos Firewall: Check client, gateway, VLAN, switch, or local routing
• Packet arrives but is not forwarded: Check firewall rule, NAT, route, or security feature
• Packet is sent into the tunnel, response is missing: Check return route, peer, remote firewall, or remote host
• Only outgoing bytes in ipsec statusall: Check return path or remote policy
• Only incoming bytes: Check local route, local firewall rule, or target system

For longer captures or support cases, it may be useful to collect logs selectively. The article Securing Sophos Firewall Logs for Support and Analysis describes the clean export.

Typical Error Patterns

The following error patterns refer to the raw StrongSwan/Charon log strings from strongswan.log. In WebAdmin, the same causes often appear as a translated message, for example no IKE config found as “Remote peer is refusing our Phase 1 proposals”, peer authentication failed as “Remote peer reports we failed to authenticate”, or traffic selectors ... inacceptable as “Remote peer reports INVALID_ID_INFORMATION”. If you check WebAdmin before the raw log, this mapping helps you find the matching case.

• no IKE config found: IKE version, gateway, IDs, or profile mismatch Compare IKE version, Local/Remote ID, and proposals
• NO_PROPOSAL_CHOSEN: Proposal mismatch Check encryption, authentication, DH group, PFS, and lifetime
• peer authentication failed: ID or authentication mismatch Check Local/Remote ID and PSK/certificate
• AUTH_FAILED: Preshared key, certificate, or ID mismatch Reset PSK, check certificate chain and IDs
• traffic selectors ... inacceptable: Local and remote networks mismatch Compare subnets and host objects mirror image
• failed to establish CHILD_SA: Phase 2 networks or ESP proposals mismatch Check traffic selectors, PFS, ESP profile, and lifetimes
• Tunnel green, no bytes: Traffic does not reach the tunnel Check firewall rule, route, NAT, and client gateway
• Outgoing bytes, no incoming: Peer or return path missing Check remote rules, remote route, and target system
• ipsec statusall shows SAs, but route-based traffic stops later: XFRM state, XFRM policy, overlapping XFRM networks, failover group and rekey behaviour
• Several tunnels with the same subnets: Tunnels belong in a failover group or need clearly different selector or routing logic
• Large transfers hang despite active tunnel: MTU/MSS, packet loss, or path MTU discovery Check MTU and MSS for VPN Problems
• SFOS 22, policy-based IPsec, tunnel green, traffic missing: NAT, default SNAT, or traffic selectors do not match cleanly after upgrade Check default SNAT, VPN NAT rules, MASQ, packet capture, and peer
• SFOS 22, PPPoE-WAN alias, tunnel green, no traffic: Possible known issue with IPsec acceleration Check interface type, SFOS version, and test system ipsec-acceleration off only deliberately
• Reconnects or frequent rekeys: Lifetime, DPD, unstable line, or proposal issue Check rekey times, DPD, WAN stability, and logs

Practical Checklist

Immediate checks:

• Note tunnel status and last error message in WebAdmin.
• Start tail -f /log/strongswan.log and reconnect the tunnel.
• Check IKE version, Local ID, Remote ID, and preshared key.
• Compare traffic selectors or local and remote networks mirror image.
• Check ipsec statusall for ESTABLISHED, INSTALLED, and byte counters.

If the tunnel is up:

• Check firewall rules in both directions.
• Enable logging on the affected rules.
• Filter Log Viewer by source, destination, and rule ID.
• Perform packet capture with a tight filter.
• Check NAT rules and route precedence.
• For route-based VPN, check ip xfrm state, ip xfrm policy and XFRM interface networks.
• For several similar tunnels, display failover group and local/remote subnet columns.
• For SFOS 22 with policy-based IPsec, check default SNAT, specific VPN NAT rules, and expected source IP.
• For SFOS 22 with PPPoE-WAN alias, check if the IPsec acceleration known issue applies.
• Confirm return route on the peer.

For support or longer analysis:

• Activate debug only briefly and then deactivate it again.
• Secure relevant logs.
• Document time, tunnel name, peer IP, source, destination, and test procedure.
• Review sensitive data before sharing.

FAQ