Skip to content

Troubleshooting site-to-site IPsec VPN

Common configuration errors that prevent Sophos Firewall devices from establishing site-to-site IPsec VPN connections.

How to check logs and IPsec properties

You can check the logs and IPsec profiles to identify the issue and check the properties.

Logs

The firewall uses the following files 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

This page helps with troubleshooting errors that relate to this error message: IPsec connection could not be established

Open the following log file: /log/strongswan.log

Failover groups

  1. Go to Site-to-site VPN > IPsec connections to see the tunnels' properties.
  2. Click Show additional properties above the name column and select the properties you want to see.

    IPsec connection's additional properties.

  3. Check the properties of the IPsec profile used in the connection.

IPsec profiles

  1. Go to Profiles > IPsec profiles to see the tunnel's properties.
  2. Click Show additional properties above the name column and select the additional properties you want to see.

    IPsec profile's additional properties.

Troubleshooting

See the following issues and their resolution.

Remote peer refuses Phase 1 proposal

The strongSwan log shows the following error message: Remote peer is refusing our Phase 1 proposals

Cause: Mismatched phase 1 proposals between the two peers.

  1. 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.
  2. 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

The strongSwan log shows the following messages:

We have successfully exchanged Encryption and Authentication algorithms, we are now negotiating the Phase 1 SA encryption (hashing) key

Remote peer reports we failed to authenticate

Cause: The remote firewall couldn't authenticate the local request because the ID types don't match. Example: You've configured the local firewall's IPsec connection with Local ID set to IP address, but the remote firewall is configured to expect a DNS name.

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

Decryption error

Logs show the following error messages:

Error on decryption of the exchange\

Information field of the IKE request is malformed or not readable

Cause: The cause is likely to be a preshared key mismatch between the two firewalls.

Rarely, the ISP or an upstream appliance, such as a router or another firewall, may corrupt the packet.

  1. Make sure the preshared key matches in the VPN configuration on both firewalls.
  2. If the preshared key matches, verify with the ISP or on the upstream devices if they've corrupted the packet.
  3. 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

The strongSwan log shows the following messages:

Phase 1 is up\

Initiating establishment of Phase 2 SA\

Remote peer reports no match on the acceptable proposals

The remote firewall shows the following error message: NO_PROPOSAL_CHOSEN

Cause: Mismatched phase 2 proposal.

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

Invalid ID

The strongSwan log shows the following messages:

Phase 1 is up\

Remote peer reports INVALID_ID_INFORMATION

Cause:

  1. Sign in to the CLI and click 5 for Device management and then click 3 for Advanced shell.
  2. Enter the following command: ipsec statusall

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

    Security association error.

  3. 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.

  4. Make sure the configured subnets match on both firewalls.

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

Tunnel established but traffic stops later

IPsec connection is established between a Sophos Firewall device and a third-party firewall. Traffic stops flowing after some time.

  1. Sign in to the CLI and click 5 for Device management and then click 3 for Advanced shell.
  2. Enter the following command: ipsec statusall

    The output shows that IPSec SAs have been established.

  3. Enter the following command: ip xfrm state

    The output shows the transform sets for the VPN exist, that is, the SAs match.

  4. To prevent key exchange collisions, follow these guidelines:

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

    Example values are as follows:

    Key life Firewall 1 Firewall 2
    Phase 1 12600 seconds 10800 seconds
    Phase 2 5400 seconds 3600 seconds
  5. Sophos Firewall only supports time-based rekeying. If you configured traffic-based rekeying on the third-party remote firewall, change it to time-based rekeying.