Project

General

Profile

Issue #2758

Cannot installed tunnel - IKE_SA checkout not successful

Added by José Antonio Chao almost 7 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Tobias Brunner
Category:
ikev1
Affected version:
5.6.3
Resolution:
No feedback

Description

Hello,

we have this scenario:

Side A - FW Juniper srx240h2
Side B - Instance server on AWS Amazon ( Centos 7 - StrongSwan 5.6.3)

We setup strongswan and, it seams, up tunnel but cannot "installed".

Here our configuration:

* /etc/strongswan/ipsec.conf

# ipsec.conf - strongSwan IPsec configuration file

# basic configuration

config setup
        # strictcrlpolicy=yes
        # uniqueids = no

# Add connections here.

# Sample VPN connections

conn %default
        ikelifetime=28800
        keylife=3600
        rekeymargin=3m
        keyingtries=1
        authby=secret
        keyexchange=ikev1
        mobike=no

conn predaufood
        left=192.168.2.9
        leftid=34.241.220.61
        leftsubnet=192.168.2.9/32
        leftfirewall=yes
        right=213.192.193.25
        rightsubnet=10.166.0.0/20
        auto=start
        esp=aes256-sha1!
        ike=aes256-sha1-modp1024!

we attach charcon.log where we can find this error:

IKE_SA checkout not successful

*strongswan statusall:

First moment:

Status of IKE charon daemon (strongSwan 5.6.3, Linux 3.10.0-862.11.6.el7.x86_64, x86_64):
  uptime: 55 seconds, since Sep 12 18:17:45 2018
  malloc: sbrk 2809856, mmap 0, used 620384, free 2189472
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 10
  loaded plugins: charon pkcs11 tpm aesni aes des rc2 sha2 sha1 md4 md5 mgf1 random nonce x509 revocation constraints acert pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl gcrypt fips-prf gmp curve25519 chapoly xcbc cmac hmac ctr ccm gcm curl attr kernel-netlink resolve socket-default farp stroke vici updown eap-identity eap-sim eap-aka eap-aka-3gpp eap-aka-3gpp2 eap-md5 eap-gtc eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap xauth-generic xauth-eap xauth-pam xauth-noauth dhcp led duplicheck unity counters
Listening IP addresses:
  192.168.2.9
Connections:
  predaufood:  192.168.2.9...213.192.193.25  IKEv1
  predaufood:   local:  [34.241.220.61] uses pre-shared key authentication
  predaufood:   remote: [213.192.193.25] uses pre-shared key authentication
  predaufood:   child:  192.168.2.9/32 === 10.166.0.0/20 TUNNEL
Security Associations (1 up, 1 connecting):
  predaufood[4]: ESTABLISHED 11 seconds ago, 192.168.2.9[34.241.220.61]...213.192.193.25[213.192.193.25]
  predaufood[4]: IKEv1 SPIs: 251dc8ac7dc4ea88_i ea26d43cc4f7a479_r*, pre-shared key reauthentication in 7 hours
  predaufood[4]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
  predaufood[1]: CONNECTING, 192.168.2.9[34.241.220.61]...213.192.193.25[%any]
  predaufood[1]: IKEv1 SPIs: 65f4f6bd2b4b9b87_i* cc4e75f36155ecfe_r
  predaufood[1]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
  predaufood[1]: Tasks queued: QUICK_MODE
  predaufood[1]: Tasks active: ISAKMP_VENDOR MAIN_MODE

After few minutes:

Status of IKE charon daemon (strongSwan 5.6.3, Linux 3.10.0-862.11.6.el7.x86_64, x86_64):
  uptime: 12 minutes, since Sep 12 18:17:46 2018
  malloc: sbrk 2809856, mmap 0, used 617552, free 2192304
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 48
  loaded plugins: charon pkcs11 tpm aesni aes des rc2 sha2 sha1 md4 md5 mgf1 random nonce x509 revocation constraints acert pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl gcrypt fips-prf gmp curve25519 chapoly xcbc cmac hmac ctr ccm gcm curl attr kernel-netlink resolve socket-default farp stroke vici updown eap-identity eap-sim eap-aka eap-aka-3gpp eap-aka-3gpp2 eap-md5 eap-gtc eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap xauth-generic xauth-eap xauth-pam xauth-noauth dhcp led duplicheck unity counters
Listening IP addresses:
  192.168.2.9
Connections:
  predaufood:  192.168.2.9...213.192.193.25  IKEv1
  predaufood:   local:  [34.241.220.61] uses pre-shared key authentication
  predaufood:   remote: [213.192.193.25] uses pre-shared key authentication
  predaufood:   child:  192.168.2.9/32 === 10.166.0.0/20 TUNNEL
Security Associations (1 up, 0 connecting):
  predaufood[24]: ESTABLISHED 23 seconds ago, 192.168.2.9[34.241.220.61]...213.192.193.25[213.192.193.25]
  predaufood[24]: IKEv1 SPIs: 13343ccf4d1c77a4_i 7ea438993b29df4d_r*, pre-shared key reauthentication in 7 hours
  predaufood[24]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024

What could be the problem?

Thanks for avance.

Regards,

José Antonio Chao

charon.log (629 KB) charon.log José Antonio Chao, 12.09.2018 18:39
charon.log (28.1 KB) charon.log José Antonio Chao, 13.09.2018 11:07

History

#1 Updated by Tobias Brunner almost 7 years ago

  • Description updated (diff)
  • Status changed from New to Feedback

Please reduce the log levels (see HelpRequests).

we attach charcon.log where we can find this error:

IKE_SA checkout not successful

That's not really the error you should focus on.

There are several detected duplicate IKE_SA... messages, which might be problematic (although it doesn't look like the SA is fully established in the first place). These are caused by the duplicheck plugin, which you almost certainly don't want to have enabled (read its description). Disable that and try again with reduced log levels and look for further clues in the log then (also on the other end if possible).

#2 Updated by José Antonio Chao almost 7 years ago

Hi Tobias,

first of all thank you for your quickly reply.

We disable duplicheck:

/etc/strongswan/strongswan.d/charon/duplicheck.conf

duplicheck {

  1. Enable duplicheck plugin (if loaded).
  2. enable = yes
  1. Whether to load the plugin. Can also be an integer to increase the
  2. priority of this plugin.
    load = no
  1. Socket provided by the duplicheck plugin.
  2. socket = unix://${piddir}/charon.dck

}

Reduce log (attach) but cannot found why don't established tunnel.

We ask about logs from other side.

Regards,

José Antonio Chao

#3 Updated by Tobias Brunner almost 7 years ago

The other end tries to constantly create new IKE_SAs without creating any CHILD_SAs. And the SA your end initiated (due to auto=start) was never completed because the peer didn't respond to the third Main Mode request. That's the first message sent from/to UDP port 4500 (due to the NAT). Maybe that port is blocked by some firewall. On the other hand, packets with that port sent by the other peer are received fine. Check what the log on the other end says.

#4 Updated by José Antonio Chao almost 7 years ago

Hi Tobias,

we thing that not is a FW issue, we thing it's NAT problem.
Our server is on AWS Amazon, where only have a private IP and Amazon provides a public IP where do a NAT over private IP.

It's necessary make special configuration over Strongswan in this scenario?

Regards,

José Antonio Chao.

#5 Updated by Tobias Brunner almost 7 years ago

It's necessary make special configuration over Strongswan in this scenario?

Not really (at least not in regards to establishing a connections). As long as both UDP ports are forwarded properly this should work (although there does seem to be some kind of source IP filter for AWS, which might be problematic, see Cloudplatforms).

#6 Updated by Tobias Brunner over 6 years ago

  • Status changed from Feedback to Closed
  • Resolution set to No feedback