1

I'm trying to create a tunnel between StrongSwan and palo alto. StrongSwan is running on a digital ocean droplet, Ubuntu. In my ipsec.conf, I have:

conn %default
    ikelifetime=28800s
    keyexchange=ikev1
    authby=psk
    type=tunnel

conn partner
    left=1.2.3.4
    leftid=1.2.3.4
    leftsubnet=10.17.0.6
    leftsourceip=10.17.0.6

    right=a.b.c.d
    rightid=a.b.c.d
    ike=aes256-sha1-modp1024!
    esp=aes256-sha1!

conn partner_ip_1
    also=partner
    rightsourceip=x.y.z.1
    rightsubnet=x.y.z.1
    auto=start

conn partner_ip_2
    also=partner
    rightsourceip=x.y.z.2
    rightsubnet=x.y.z.2
    auto=start

conn partner_ip_3
    also=partner
    rightsourceip=x.y.z.3
    rightsubnet=x.y.z.3
    auto=start

conn partner_ip_4
    also=partner
    rightsourceip=x.y.z.4
    rightsubnet=x.y.z.4
    auto=start

I'm able to establish connection but can't send/receive any traffic. My partner shared these configs from their end: enter image description here enter image description here

Everything else is default on my end. How can I get this working please? Below are the logs from ipsec statusall

Status of IKE charon daemon (strongSwan 5.8.4, Linux 5.8.0-25-generic, x86_64):
  uptime: 6 days, since Nov 09 17:55:31 2020
  malloc: sbrk 7458816, mmap 0, used 1614864, free 5843952
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 2786
  loaded plugins: charon aesni aes rc2 sha2 sha1 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm drbg attr kernel-netlink resolve socket-default connmark stroke updown eap-mschapv2 xauth-generic counters
Virtual IP pools (size/online/offline):
  x.y.z.1: 1/0/0
  x.y.z.2: 1/0/0
  x.y.z.3: 1/0/0
  x.y.z.4: 1/0/0
Listening IP addresses:
  1.2.3.4
  10.17.0.6
Connections:
partner_ip_1:  1.2.3.4...a.b.c.d  IKEv1
partner_ip_1:   local:  [1.2.3.4] uses pre-shared key authentication
partner_ip_1:   remote: [a.b.c.d] uses pre-shared key authentication
partner_ip_1:   child:  10.17.0.6/32 === x.y.z.1/32 TUNNEL
partner_ip_2:  1.2.3.4...a.b.c.d  IKEv1
partner_ip_2:   local:  [1.2.3.4] uses pre-shared key authentication
partner_ip_2:   remote: [a.b.c.d] uses pre-shared key authentication
partner_ip_2:   child:  10.17.0.6/32 === x.y.z.2/32 TUNNEL
partner_ip_3:  1.2.3.4...a.b.c.d  IKEv1
partner_ip_3:   local:  [1.2.3.4] uses pre-shared key authentication
partner_ip_3:   remote: [a.b.c.d] uses pre-shared key authentication
partner_ip_3:   child:  10.17.0.6/32 === x.y.z.3/32 TUNNEL
partner_ip_4:  1.2.3.4...a.b.c.d  IKEv1
partner_ip_4:   local:  [1.2.3.4] uses pre-shared key authentication
partner_ip_4:   remote: [a.b.c.d] uses pre-shared key authentication
partner_ip_4:   child:  10.17.0.6/32 === x.y.z.4/32 TUNNEL
Security Associations (4 up, 0 connecting):
partner_ip_1[23522]: ESTABLISHED 28 seconds ago, 1.2.3.4[1.2.3.4]...a.b.c.d[a.b.c.d]
partner_ip_1[23522]: IKEv1 SPIs: dfbe7dc560a6fd5f_i* d77aad31ae64bb47_r, pre-shared key reauthentication in 7 hours
partner_ip_1[23522]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
partner_ip_1[23522]: Tasks queued: QUICK_MODE 
partner_ip_3[23521]: ESTABLISHED 37 seconds ago, 1.2.3.4[1.2.3.4]...a.b.c.d[a.b.c.d]
partner_ip_3[23521]: IKEv1 SPIs: 60f983e4761ce5be_i* b7c41e54042b4728_r, pre-shared key reauthentication in 7 hours
partner_ip_3[23521]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
partner_ip_3[23521]: Tasks queued: QUICK_MODE 
partner_ip_4[23520]: ESTABLISHED 61 seconds ago, 1.2.3.4[1.2.3.4]...a.b.c.d[a.b.c.d]
partner_ip_4[23520]: IKEv1 SPIs: 3da4b052f8791e72_i* 32706fa421f1c60b_r, pre-shared key reauthentication in 7 hours
partner_ip_4[23520]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
partner_ip_4[23520]: Tasks queued: QUICK_MODE 
partner_ip_2[23519]: ESTABLISHED 89 seconds ago, 1.2.3.4[1.2.3.4]...a.b.c.d[a.b.c.d]
partner_ip_2[23519]: IKEv1 SPIs: 3cb5b1ec27787487_i* 4795fa19c8b86504_r, pre-shared key reauthentication in 7 hours
partner_ip_2[23519]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
partner_ip_2[23519]: Tasks queued: QUICK_MODE
  • 1
    Is there a reason you use IKEv1 when the box apparently supports IKEv2 (at least the screenshot seems to indicate that)? (The screenshots are also both the same, maybe you wanted to post the IPsec/ESP settings in the second?) The actual logs might help to determine why Quick Mode is not successful here. – ecdsa Nov 16 '20 at 14:21
  • @ecdsa From the configuration document they had shared it had indicated that they use ikev1 – Wafula Samuel Nov 16 '20 at 14:58

0 Answers0