Troubleshooting site-to-site IPsec VPN

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

Sophos 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

Remote peer refuses Phase 1 proposal

The strongSwan log shows the following error: 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 errors:

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: 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. Make sure the key life value is the same on both firewalls.

    If it doesn't match, one firewall rekeys the ESP encryption secrets before the remote peer can allow it.

  5. If the key life matches, make sure rekeying is based on key life.

    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.