Project

General

Profile

Issue #432

establishing IKE_SA failed

Added by Dariusz Zawadzki almost 12 years ago. Updated almost 11 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Tobias Brunner
Category:
configuration
Affected version:
5.1.0
Resolution:
No feedback

Description

Hello all,

I'm struggling with this for a week now and I cannot resolve this issue. Imho it is worth to look on it because of non-standard setup.

THE TASK:
Create a VPN tunnel between Amazon EC2 instance and 3rd party company (Cisco router)

DIFFERENCES:
Amazon instance is not a VPN gateway, it is a peer and destination host instance. In shortcut: packages are not forwarded to other hosts.

PARAMETERS:
IKE Parameters (Phase 1)
- IKE protocol IKE2
- IKE Encryption 3DES
- Authentication Method MD5
- Diffie-Helman Group 2
- Security Association Lifetime (sec) 28800
- Pre-share Key "key"

IPSec Parameters (Phase 2)
- IPSec Encryption 3DES
- Authentication Method MD5
- Diffie-Helman Group N/A
- Security Association Lifetime (sec) 3600

VPN Device Cisco 2800
Encryption Domain/Access Needed
Subnet Protocol
10.xxx.yyy.123/32 tcp/9999
10.xxx.yyy.456/32 tcp/9999
10.xxx.yyy.789/32 tcp/9999

I have no access to the cisco router and unfortunately have no logs from this side. I have a simmilar WORKING connection but using IKE1. I'm using a strongswan 5.1.0. The 3rd party company also have more than 20 actives tunnels and no errors when creating new one, except my case.

My config (experimental):

config setup

conn %default
        auto=start

conn VPN
        type=tunnel
        ike=3des-md5-modp1024
        ikelifetime=28800s
        keyexchange=ikev2
        esp=3des-md5
        lifetime=3600s
        left=<amazon private IP>
        leftsubnet=0.0.0.0/0
        leftfirewall=yes
        leftid=<amazon elastic IP>
        leftauth=psk
        right=<3rd party peer IP>
        rightfirewall=yes
        rightsubnet=10.xxx.yyy.123/32,10.xxx.yyy.456/32,10.xxx.yyy.789/32
        rightprotoport=tcp/9999
        rightauth=psk

My ipsec.secrets

<amazon elastic IP> : PSK "psk_key" 
<3rd party peer IP> : PSK "psk_key"

The problem is that this tunnel won't comes up:

charon: 03[IKE] initiating IKE_SA VPN to <3rd party peer IP>
charon: 03[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
charon: 03[NET] sending packet: from <amazon private IP>[500] to <3rd party peer ip>[500] (536 bytes)
charon: 02[IKE] retransmit 1 of request with message ID 0
charon: 02[NET] sending packet: from <amazon private IP>[500] to <3rd party peer ip>[500] (536 bytes)
charon: 01[IKE] retransmit 2 of request with message ID 0
charon: 01[NET] sending packet: from <amazon private IP>[500] to <3rd party peer ip>[500] (536 bytes)
charon: 05[IKE] retransmit 3 of request with message ID 0
charon: 05[NET] sending packet: from <amazon private IP>[500] to <3rd party peer ip>[500] (536 bytes)
charon: 12[IKE] retransmit 4 of request with message ID 0
charon: 12[NET] sending packet: from <amazon private IP>[500] to <3rd party peer ip>[500] (536 bytes)
charon: 11[IKE] retransmit 5 of request with message ID 0
charon: 11[NET] sending packet: from <amazon private IP>[500] to <3rd party peer ip>[500] (536 bytes)
charon: 14[IKE] giving up after 5 retransmits
charon: 14[IKE] establishing IKE_SA failed, peer not responding

the FW are correctly configured

Any suggestions highly appreciated!

History

#1 Updated by Tobias Brunner almost 12 years ago

  • Description updated (diff)
  • Status changed from New to Feedback
  • Assignee set to Tobias Brunner

Well, without having any more information from that other end (logs etc.), it simply looks like the Cisco device does not accept IKEv2 packets (at least if you can rule out generic firewall issues).

Did you try IKEv1?

#2 Updated by Dariusz Zawadzki almost 12 years ago

Hello Tobias,

thank you for your response. You had right in place that this is not IKEv2 and to try IKEv1 instead... When try ike1, phase 1 was passed without problem, and error appear in phase 2.
But here I have an another question:

charon: 14[IKE] IKE_SA vpn[1] established between <amazon private IP>[<amazon elastic IP>]...<3rd party IP>[<3rd party IP>]
charon: 14[IKE] scheduling reauthentication in 27817s
charon: 14[IKE] maximum IKE_SA lifetime 28357s
charon: 14[ENC] generating QUICK_MODE request 2404593121 [ HASH SA No KE ID ID ]
charon: 14[NET] sending packet: from <amazon private IP>[4500] to <3rd party IP>[4500] (308 bytes)
charon: 15[NET] received packet: from <3rd party IP>[4500] to <amazon private IP>[4500] (124 bytes)
charon: 15[ENC] parsed INFORMATIONAL_V1 request 2994204254 [ HASH N(NO_PROP) ]
charon: 15[IKE] received NO_PROPOSAL_CHOSEN error notify

3rd party required in phase 2 to have psf=no, but right now this parameter is deprecated in v5.1.0, is there any way to set psf=no?

#3 Updated by Tobias Brunner almost 12 years ago

3rd party required in phase 2 to have psf=no, but right now this parameter is deprecated in v5.1.0, is there any way to set psf=no?

You already did that by configuring the esp option without DH group:

esp=3des-md5

The problem may be caused by a mismatch in traffic selectors (TS). It could be that the Cisco device doesn't like leftsubnet=0.0.0.0/0. There is usually no TS narrowing for IKEv1, so the TS have to match exactly on both sides.

When using IKEv1 you also have to split rightsubnet, that is, the following only works with IKEv2:

rightsubnet=10.xxx.yyy.123/32,10.xxx.yyy.456/32,10.xxx.yyy.789/32

With IKEv1 you have to do something like this:

conn %default
        type=tunnel
        ike=3des-md5-modp1024
        ikelifetime=28800s
        keyexchange=ikev1
        esp=3des-md5
        lifetime=3600s
        left=<amazon private IP>
        leftsubnet=<0.0.0.0/0 or whatever you have to change it to>
        leftfirewall=yes
        leftid=<amazon elastic IP>
        leftauth=psk
        right=<3rd party peer IP>
        rightprotoport=tcp/9999
        rightauth=psk  
        auto=start

conn VPN-123
        rightsubnet=10.xxx.yyy.123/32

conn VPN-456
        rightsubnet=10.xxx.yyy.456/32

conn VPN-789
        rightsubnet=10.xxx.yyy.789/32

#4 Updated by Tobias Brunner almost 11 years ago

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