Sophos XG: Troubleshooting site to site IPsec VPN issues

Disclaimer: This information is posted as-is and the content should be referenced at your own risk.


Hi Community,

The purpose of this post is to help understand troubleshooting steps and explain how to fix the most common IPsec issues that can be encountered while using the Sophos XG Firewall IPsec VPN(site to site) feature.


Strongswan is the service used by Sophos XG to provide IPSec functionality. We will put strongswan service in debug while we troubleshoot IPsec VPN issues.

  • Steps to put the strongswan service in debug:
    • SSH into the XG firewall by following this KBA: Sophos XG Firewall: How to SSH to the firewall using PuTTY utility
      • To connect using SSH, you may use any SSH client to connect to port 22 of the SFOS device.
      • Select option 5 Device Management.
      • Select option 3 Advanced Shell.
    • To put the strongswan service in debug, type the following command: service strongswan:debug -ds nosync
      • Output
        • SFVUNL_AZ01_SFOS 18.0.3 MR-3# service strongswan:debug -ds nosync
          200 OK
    • Run the following command to check the status of the service: service -S | grep strongswan
      • Output
        • SFVUNL_AZ01_SFOS 18.0.3 MR-3# service -S | grep strongswan
          strongswan RUNNING,DEBUG
    • 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 there are multiple IPsec tunnels.

Problem #1 - Incorrect traffic selectors (SA)

Verify networks being presented by both local and remote ends match

This issue may occur if the networks being negotiated on either end of the tunnels do not match on both ends. Verify the network objects on either end match exactly down to the correct subnets and even individual addresses.

2020-09-20 00:25:13 05[NET] <Azure_to_XG-1|9> received packet: from 72.138.xx.xx[4500] to 10.0.0.4[4500] (1168 bytes)

2020-09-20 00:25:13 05[ENC] <Azure_to_XG-1|9> parsed CREATE_CHILD_SA request 2 [ SA No KE TSi TSr ]

2020-09-20 00:25:13 05[CFG] <Azure_to_XG-1|9> looking for a child config for 10.0.1.0/24 === 172.16.19.0/24

2020-09-20 00:25:13 05[IKE] <Azure_to_XG-1|9> traffic selectors 10.0.1.0/24 === 172.16.19.0/24 inacceptable

2020-09-20 00:25:13 05[DMN] <Azure_to_XG-1|9> [GARNER-LOGGING] (child_alert) ALERT: the received traffic selectors did not match: 172.16.19.0/24 === 10.0.1.0/24 << Local and remote network did not match.

2020-09-20 00:25:13 05[IKE] <Azure_to_XG-1|9> failed to establish CHILD_SA, keeping IKE_SA

Problem #2 - No IKE config found

Verify configured IKE version on policies. This issue may occur if IKE version mismatch with the configured policy of the firewalls

Logs on remote(respond only) XG firewall

2020-09-24 18:51:19 13[NET] <100> received packet: from 72.138.xx.xx1[500] to 10.0.0.4[500] (872 bytes)

2020-09-24 18:51:19 13[ENC] <100> parsed ID_PROT request 0 [ SA V V V V V V ]

2020-09-24 18:51:19 13[CFG] <100> looking for an ike config for 10.0.0.4...72.138.xx.xx

2020-09-24 18:51:19 13[IKE] <100> no IKE config found for 10.0.0.4...72.138.xx.xx, sending NO_PROPOSAL_CHOSEN

2020-09-24 18:51:19 13[ENC] <100> generating INFORMATIONAL_V1 request 1316998708 [ N(NO_PROP) ]

2020-09-24 18:51:19 13[NET] <100> sending packet: from 10.0.0.4[500] to 72.138.107.211[500] (40 bytes)

2020-09-24 18:51:19 13[IKE] <100> IKE_SA (unnamed)[100] state change: CREATED => DESTROYING

Logs on Local(Initiator) XG firewall

2020-09-24 09:50:54 06[NET] <To_Azure_XG-1|108> received packet: from 40.84.xx.xx [500] to 192.168.1.16[500] (40 bytes)

2020-09-24 09:50:54 06[ENC] <To_Azure_XG-1|108> parsed INFORMATIONAL_V1 request 1316998708 [ N(NO_PROP) ]

2020-09-24 09:50:54 06[IKE] <To_Azure_XG-1|108> informational: received NO_PROPOSAL_CHOSEN error notify

2020-09-24 09:50:54 06[IKE] <To_Azure_XG-1|108> IKE_SA NO_PROPOSAL_CHOSEN set_condition COND_START_OVER

2020-09-24 09:50:54 06[IKE] <To_Azure_XG-1|108> flush_queue(IKE_MOBIKE)

2020-09-24 09:50:54 06[IKE] <To_Azure_XG-1|108> ### destroy: 0x7f9b88001f80

2020-09-24 09:50:54 06[IKE] <To_Azure_XG-1|108> flush_queue(IKE_NATD)

2020-09-24 09:50:54 06[IKE] <To_Azure_XG-1|108> flush_queue(IKE_INIT)

2020-09-24 09:50:54 06[IKE] <To_Azure_XG-1|108> IKE_SA has_condition COND_START_OVER retry initiate in 60 sec

2020-09-24 09:50:54 06[IKE] <To_Azure_XG-1|108> IKE_SA To_Azure_XG-1[108] state change: CONNECTING => DESTROYING

Problem #3 - ALERT: peer authentication failed

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

The message “no matching peer config found” indicated that the connection ID was not configured to match on both sites. The remote ID has to match the configured ID or phase 1 will not come up, and thus the IPsec VPN will not work.

2020-09-20 00:29:42 22[NET] <10> received packet: from 72.138.xx.xx[4500] to 10.0.0.4[4500] (464 bytes)

2020-09-20 00:29:42 22[ENC] <10> parsed IKE_AUTH request 1 [ IDi IDr AUTH SA TSi TSr N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]

2020-09-20 00:29:42 22[CFG] <10> looking for peer configs matching 10.0.0.4[10.0.0.1]...72.138.xx.xx[72.138.xx.xx]

2020-09-20 00:29:42 22[CFG] <10> no matching peer config found

2020-09-20 00:29:42 22[DMN] <10> [GARNER-LOGGING] (child_alert) ALERT: peer authentication failed

2020-09-20 00:29:42 22[ENC] <10> generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]

2020-09-20 00:29:42 22[NET] <10> sending packet: from 10.0.0.4[4500] to 72.138.xx.xx[4500] (96 bytes)

2020-09-20 00:29:42 22[IKE] <10> IKE_SA (unnamed)[10] state change: CONNECTING => DESTROYING

2020-09-20 00:29:42 04[NET] sending packet: from 10.0.0.4[4500] to xx.xx[4500]

Problem #4 - Traffic does not pass through the IPsec VPN Tunnel

Sophos XG Firewall: Troubleshooting steps when traffic is not passing through the VPN tunnel

  • Verify the IPsec configuration.
  • Verify if firewall rules are created to allow VPN traffic.
  • Verify the priority of VPN and static routes.
  • Ensure that traffic from LAN hosts passes through the Sophos XG Firewall.
  • Verify the IPsec connection status with the following command: “Ipsec statusall

SFVUNL_VM01_SFOS 17.5.14 MR-14-1# ipsec statusall

Status of IKE charon daemon (strongSwan 5.5.3, Linux 3.14.22, x86_64):

uptime: 4 hours, since Oct 27 05:11:10 2020

malloc: sbrk 4927488, mmap 0, used 550176, free 4377312

worker threads: 27 of 32 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 5

loaded plugins: charon aes des rc2 sha2 sha3 sha1 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem  openssl fips-prf curve25519 xcbc cmac hmac attr kernel-netlink socket-default stroke vici xauth-generic xauth-access-server ippool-access-server cop-updown garner-logging error-notify unity

Listening IP addresses:

  169.254.xx.xx

  172.16.19.16

  192.168.1.16

  10.255.0.1

  10.81.235.10

  2001:db8::1:0

Connections:

To_Azure_XG-1:  192.168.1.16...xxxxxx.eastus2.cloudapp.azure.com  IKEv2, dpddelay=30s

To_Azure_XG-1:   local:  [72.138.XX.XX] uses pre-shared key authentication

To_Azure_XG-1:   remote: [10.0.0.4] uses pre-shared key authentication

To_Azure_XG-1:   child:  172.16.19.0/24 === 10.0.1.0/24 TUNNEL, dpdaction=restart

Security Associations (1 up, 0 connecting):

To_Azure_XG-1[11]: ESTABLISHED 6 minutes ago, 192.168.1.16[72.138.xx.xx]...52.179.xx.xx[10.0.0.4]

To_Azure_XG-1[11]: IKEv2 SPIs: de12479abd022538_i* e9aa15057931f8d2_r, rekeying in 77 minutes

To_Azure_XG-1[11]: IKE proposal: AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/CURVE_25519

To_Azure_XG-1{11}:  INSTALLED, TUNNEL, reqid 6, ESP in UDP SPIs: c2a06117_i ce6446d0_o

To_Azure_XG-1{11}:  AES_CBC_256/HMAC_SHA2_512_256, 0 bytes_i, 0 bytes_o, rekeying in 14 minutes

To_Azure_XG-1{11}:   172.16.19.0/24 === 10.0.1.0/24

  • Verify the IPsec route by running the following command: “Ip route show table 220

SFVUNL_VM01_SFOS 17.5.14 MR-14-1# ip route show table 220

10.0.1.0/24 dev ipsec0  scope link  src 172.16.19.16

Check out the following KBA for a more detailed explanation on troubleshooting other IPsec problems

Related links

Regards,



Updated the tail command.
[edited by: H_Patel at 4:15 PM (GMT -8) on 4 Nov 2020]