Thread Info
Options

Sophos Firewall: Consolidation of IPsec Troubleshooting

Erick Jan

Disclaimer: This information is provided as-is for the benefit of the Community. Please contact Sophos Professional Services if you require assistance with your specific environment.

Overview

This recommended read consolidates troubleshooting IPsec Site-site VPN and the steps and fixes for the issues encountered using the Sophos Firewall IPsec VPN. 

IPsec VPN and Configuration

IPsec encrypts and authenticates one or multiple packets, thus allowing secure and secret communication between two trusted points over an untrusted network.

Ipsec Logs

VPN logs are very useful for initial troubleshooting because they provide detailed information about the VPN connection process and any issues that may arise

By analyzing these logs, you can quickly narrow down potential causes of VPN issues, making it an excellent first step in troubleshooting.

The following files are located in /log to trace the IPsec events:

  • strongswan.log: IPsec VPN service log
  • charon.log: IPsec VPN charon (IKE daemon) log
  • strongswan-monitor.log: IPsec daemon monitoring log
  • dgd.log: Dead Gateway Detection (DGD) and VPN failover log

For more log details, kindly refer to the following KB

Accessing Command Line Console

To access the Shell, SSH into Sophos and select option 5. Device Management and 3. Advanced Shell. For detailed instructions, refer to the following KB

Debugging Strongswan log

Sophos uses Strongswan to provide IPSec functionality. Putting the Strongswan service in debug mode while troubleshooting IPsec VPN issues.

  • Under Advanced shell
  • Type the following command: service strongswan:debug -ds nosync
    • Output
      • # service strongswan:debug -ds nosync
        200 OK
  • Run the following command to check the status of the service: service -S | grep strongswan
    • Output
      • # service -S | grep strongswan
        strongswan RUNNING,DEBUG
        strongswan-ctl UNTOUCHED

Note: Run the same command to remove the service from the debug.

  • To check the live logs, run the following command from Advanced Shell: tail -f /log/strongswan.log
  • The less command allows you to parse through the static log files. You can also match keywords within the logs by entering /<keyword or string>
    • less /log/strongswan.log
  • The grep command applies a search filter for the keyword within the logs.
    • grep ‘<Keyword/String>’ /log/strongswan.log 
    • You could filter logs with the tunnel name if multiple IPsec tunnels exist.

Ipsec Essentials

For a tunnel to connect, the below entries need to be completed.

  • Both ends must be reachable on ports 500, 4500 (public IPs or NAT traversal if behind NAT).
  • ISP allows UDP 500, 4500, ESP (or NAT-T enabled)
  • Phase 1 settings (encryption, hashing, DH group) match
  • Phase 2 settings (PFS, encryption, hashing, traffic selectors) match
  • Matching IP/Network SA in local and remote Firewall 
  • MTU/MSS adjusted for stability

Configurations for establishing an IPsec tunnel.

  • Key exchange: select an IKE version for phase 1 and phase 2 exchanges:
  • IKEv1
  • IKEv2: It's faster and more secure with additional benefits, such as NAT traversal.
  • (Only IKEv1) For Authentication mode, select a mode for the phase 1 Diffie–Hellman key exchange from the following:
    • Main mode: Executes three two-way exchanges and is secure. IKEv2 always uses the main mode.

    • Aggressive mode: Executes the key exchange in three messages, and authentication information is sent in clear text.

Phase 1 Settings

This phase establishes an encrypted tunnel between the two firewalls. The following settings are necessary.

  • Key life and re-key connections

    • It’s the lifetime of the Security Association(SA). When the SA is about to expire, key negotiation starts again if you've selected a Re-key connection, a new SA is established, or the connection is terminated.

Note: To prevent key exchange collisions, follow these guidelines:

  • Set the initiator's key life lower than the responder's.
  • Set the phase 2 key life lower than the phase 1 value in both firewalls.

For example, see the values in the default profiles of the initiator's branch office (IKEv2) and the responder's head office (IKEv2).

  1. Re-key margin: The negotiation attempt starts when this time remains in the key life.
  2.  Randomize re-keying margin: This is the percentage value by which the re-key margin is randomized.
  • Encryption and Authentication Settings
    1. The DH group (Diffie–Hellman group)
      • This selects the groups to determine the key strength in the key exchange. 
    2. Algorithm
      1. Encryption
      2. Authentication

Phase 2 Settings

This secure data transfer through the tunnel.

  • PFS group (Perfect Forward Secrecy): This forces a new key exchange for each phase 2 tunnel.
    1. None: Turn off PFS
      • We don't recommend selecting this option. If the Phase 1 keys are compromised, all Phase 2 sessions can be decrypted. Use this option only if the remote peer is a third-party firewall not supporting PFS. 

    2. Same as phase 1: Uses phase 1 DH groups for phase 2 negotiations.

      For the other options, the firewall uses the DH group you specify for phase 2 session keys. We recommend selecting a DH group

  • Key life is the length of time that a negotiated IKE SA key is effective. It's the lifetime of the Security Association (SA). 

Note: To prevent key exchange collisions

  • Set the initiator's key life lower than the responder's.
  • Set the phase 2 key life lower than the phase 1 value in both firewalls.

Algorithm

  • Encryption
  • Authentication

Note: To ensure integrity in data exchange, you can select up to three encryption and authentication algorithms.

You must configure at least one of these combinations in the remote firewall.

Dead Peer Detection

This configuration detects unresponsive peers before data is sent if the phase 2 tunnel has remained idle.

For reference, kindly see: 

MTU/MSS (more details)

Open Ports Needed

Open port 500 & 4500 for inbound/outbound(ISP level for both ends

  • To verify, do tcpdumps, drppkt on port 500,4500
  • Tcpdump will NOT include ipsec0 egress packets

How to TCPDump

Troubleshooting

VPN Tunnel does not connect

The strongSwan log shows the following error message

  • Remote peer refuses Phase 1 proposal.

    • Make sure the VPN configuration on both firewalls has the same settings for the following:

      Phase 1: Encryption, authentication, and DH group.
      Gateway address: The peer gateway address you've entered on the local firewall matches the listening interface in the remote configuration.
      Other settings: Local and remote IDs.

    • If all the settings match, the remote firewall administrator must check the configuration at their end since the remote firewall has refused the connection.

  • Remote peer doesn't authenticate

    • Check the logs on the remote firewall to ensure the mismatch of ID types has resulted in the error.
    • Update the local and remote ID types and IDs with matching values on both firewalls.

  • Error on decryption of the exchange

    • Make sure the pre-shared key matches the VPN configuration on both firewalls.
      If the preshared key matches, verify with the ISP or on the upstream devices if they've corrupted the packet.
    • Make sure the WAN interface's MTU and MSS settings match the values given by the ISP.

  • Remote peer reports no match on the acceptable proposals

    • Ensure the phase 2 settings for encryption and authentication algorithms and DH group match on both firewalls.
    • If they match, check the remote firewall logs for the cause.

  • Invalid ID

    • Sign in to the CLI, click 5 for Device management, and then click 3 for Advanced shell.

    • Enter the following command: ipsec statusall

      You can see that the SA (Security Association) isn't shown. See the following image:

    • Enter the following command: ip xfrm policy

      The output doesn't show the phase 2 SAs. During the phase 2 negotiation, the local and remote subnets specified on the firewalls didn't match. For example, the remote firewall expects 192.168.0.0/24, but the local firewall tries to negotiate using 192.168.1.0/24.

    • Make sure the configured subnets match on both firewalls.

    • If the subnets match, the remote administrator must check the remote firewall's logs if the error persists.

  • IPsec connections are established, but traffic stops later

    • Cause: Third-party remote firewall uses traffic-based rekeying.

      Resolution: Sophos Firewall only supports time-based rekeying. If you've configured traffic-based rekeying on the third-party remote firewall, change it to time-based rekeying.

    •  Two or more IPsec connections have the same local and remote subnets (including Any-Any configurations) but aren't in the same failover group.

      Resolution: Multiple IPsec connections with the same local and remote subnets (including Any-Any configurations) only work if the IPsec connections are in the same failover group. To resolve this issue, do as follows:

      1. Go to Site-to-site VPN > IPsec.
      2. Under IPsec connections, click Show additional properties.
      3. Select the Local subnet and Remote subnet.

      4. Click OK.

        The Local subnet and Remote subnet columns appear. Check the IPsec connections that have similar local and remote subnet configurations.

        Example:

      5. Configure the IPsec connections with similar local and remote subnet configurations in the same failover group.

      6. If you don't want to configure them in the same failover group, change those IPsec connections' local and remote subnet configurations and ensure they aren't similar.

    •  For route-based VPN, two or more XFRM interfaces are configured with an IP address that belongs to the same network address or has overlapping subnets.

      Resolution: Each XFRM interface must be in a unique network address and can't have overlapping subnets.

      For example, if xfrm1 is configured with 192.168.0.1/24 and xfrm2 is configured with 192.168.0.6/24They're at the same network address, a routing issue occurs. Another example is if xfrm1 configured with and 192.168.0.6/24the subnets overlap, a routing issue occurs.

      To resolve this issue, go to Network > Interfaces and change the IP address configuration of the XFRM interfaces that are in the same network or have overlapping subnets

    • Cause: The idle timeout is set on the remote firewall for policy-based VPN.

      Resolution: Turn off the idle timeout on the remote firewall.

    • Cause: Key exchange collisions.

      Resolution: To prevent key exchange collisions, do as follows:

      1. Set the initiator's phase 1 and phase 2 key life values lower than the responder's.

      2. Set the phase 2 key life lower than the phase 1 value in both firewalls.

        Example:

        Key life Firewall 1 Firewall 2
        Phase 1 12600 seconds 10800 seconds
        Phase 2 5400 seconds 3600 seconds

The IPsec connection is disconnected because the associated interface has been turned off.

If your site-to-site IPsec connection is disconnected, check if you have turned off the associated interface.

If you've turned off the associated interface:

  • Site-to-site IPsec connection initiators immediately disconnect the connection.
  • Site-to-site IPsec connection responders and remote access connections disconnect the connection when inactivity or Dead Peer Detection (DPD) time-out occurs

Kindly refer to the following KB:

Traffic isn’t passing through the VPN tunnel

This would fall under misconfiguration of IPsec, firewall rules, VPN, static routes, or its priorities.

To troubleshoot, verify the following:

  • IPsec configuration(Local and remote subnets are correct)
  • If firewall rules are created to allow VPN traffic.
  • The priority of VPN and static routes.
  • Traffic from LAN hosts passes through the Sophos Firewall.
  • IPsec connection status with the following command: “Ipsec statusall”

Kindly refer to the following KB:

The network traffic isn’t reaching

Established tunnel, but traffic isn’t reaching. Kindly check the following. 

  • Route of packet
  • Drop packets and TCPDump
  • SDWAN routing(precedence)

Intermittent Connectivity between Sophos and Remote Machines

Avoid using overlapping subnets in local subnet configurations, for example, 172.16.16.0/24, 172.16.16.0/27, or 172.16.16.254/32, as this might cause issues with traffic, especially ICMP packets or SA rekeys.

For more reference, kindly see KB:

Common Issues

  • Incorrect traffic selectors (SA)

    • Verify the networks being presented by both local and remote ends match

  • No IKE config found

    • Verify the configured IKE version on policies. This issue may occur if the IKE version mismatches with the configured policy of the firewall logs on the remote(respond only) Sophos firewall.

  • ALERT: peer authentication failed.

    • Check the configured remote and local connection ID. This issue may occur if a mismatched local and remote connection ID is configured.

  • Invalid HASH_V1 payload length, decryption failed? & Parsed IKE_AUTH response1[N(AUTH_FAILED)]

    • Verify the pre-shared key on both firewalls. This issue may occur if the Preshared Key mismatch for the configured IPsec connection.  Logs using IKEv1 for the key exchange.

For more reference, kindly see KB

Local Subnet Becomes Unreachable due to Inactivity

Hub and Spoke

Need to forward Traffic to other VPN Sites

Kindly refer to the following KB:

IPSec VPN with no Public IP Address

Need to configure IPsec behind a router with no Public IP address

Kindly refer to the following KB:

Overlapping Network

Configure Network Address Translation (NAT) for route-based IPsec VPN tunnels when the subnets in the local and remote firewalls are the same.

Kindly refer to the following KB:



Editing
[edited by: Erick Jan at 3:18 AM (GMT -7) on 24 Mar 2025]
Unfiltered HTML