Issue #961
Strongswan not connecting
Description
HI All, I have been struggling to resolve this issue for over 2 weeks now with no head way.
im configuring a site-to-site vpn with centos7 and strongswan 5.2, when try to start the vpn connect
i get the showing errors
initiating IKE_SA mtn-zin[1] to 41.220.79.242 generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ] sending packet: from 178.79.179.231[500] to 41.220.79.242[500] (300 bytes) retransmit 1 of request with message ID 0 sending packet: from 178.79.179.231[500] to 41.220.79.242[500] (300 bytes) retransmit 2 of request with message ID 0 sending packet: from 178.79.179.231[500] to 41.220.79.242[500] (300 bytes) retransmit 3 of request with message ID 0 sending packet: from 178.79.179.231[500] to 41.220.79.242[500] (300 bytes) retransmit 4 of request with message ID 0 sending packet: from 178.79.179.231[500] to 41.220.79.242[500] (300 bytes) retransmit 5 of request with message ID 0 sending packet: from 178.79.179.231[500] to 41.220.79.242[500] (300 bytes) giving up after 5 retransmits establishing IKE_SA failed, peer not responding
Please i need help on this. Thanks
History
#1 Updated by Tobias Brunner over 10 years ago
- Description updated (diff)
- Status changed from New to Feedback
- Priority changed from High to Normal
Is that IP reachable at all by the client? Is there a firewall between the two hosts (or on the hosts themselves) that might block traffic from/to UDP port 500/4500? Is an IKE daemon actually running on host 41.220.79.242?
#2 Updated by kabir idris over 10 years ago
Hi Tobias,
Im integrating with a company to provide me some services(I think they are using Cisco devices).
they gave me a gateway server IP : 41.220.79.242(which is reachable when i ping it)
and a host server : xx.xxx.xx.xx
with the following also
Transform set : esp-aes-256 esp-md5-hmac
keyexchange : ikev1
however, the error has changed a bit
sending packet: from 178.79.179.xxx[500] to 41.220.xx.xxx[500] (212 bytes) sending retransmit 1 of request message ID 0, seq 1 sending packet: from 178.79.179.xxx[500] to 41.220.xx.xxx[500] (212 bytes) sending retransmit 2 of request message ID 0, seq 1 sending packet: from 178.79.179.xxx[500] to 41.220.xx.xxx[500] (212 bytes)
this is my ipsec.conf
conn blink-zin
keyexchange=ikev1
left=178.79.xxx.xxx
leftsubnet=172.16.48.16/28
right=41.220.xxx.xxx
rightsubnet=10.2.0.0/24
auto=add
authby=secret
ikelifetime=60m
keylife=20m
keyingtries=1
leftid=@zin
rightid=@blink
leftfirewall=yes
type=tunnel
forceencaps=yes
ike=3des-md5-modp1024
mobike=no
leftprotoport=udp/%any
rightprotoport=udp/%any
esp=3des-md5;modp1024
leftauth=psk
rightauth=psk
#3 Updated by Tobias Brunner over 10 years ago
keyexchange : ikev1
The messages that were sent initially (as seen in your original report), were not IKEv1 but IKEv2 instead. Now it seems IKEv1 messages are being sent (we don't see the message type but ..., seq x is only logged for IKEv1). You should check with the other company, whether messages arrive at their gateway. Maybe they even see some messages in their log which could help you debug this.
This does not matter just yet, but there is a typo in esp=3des-md5;modp1024, should be esp=3des-md5-modp1024 (or even aes256 instead of 3des, as that's what you wrote is the designated ESP transform). You should also confirm whether the other peer uses PFS, if not you have to remove modp1024.
#4 Updated by kabir idris over 10 years ago
the company said PFS should be "no"
pfs=no
i found this in the my /var/log/secure
pluto1854: packet from 41.220.79.242:500: phase 1 message is part of an unknown exchange
#5 Updated by Martin Willi over 10 years ago
pluto[1854]: packet from 41.220.79.242:500: phase 1 message is part of an unknown exchange
It seems that you have another IKE daemon running on your box, either strongSwan 4.x, OpenSwan or Libreswan. If you want to use strongSwan 5.x, make sure to remove any such installation and that no pluto daemon is running. With strongSwan 5.x both IKEv1 and IKEv2 are handled in the charon daemon.
#6 Updated by kabir idris over 10 years ago
Hi, I have removed the libreswan.
now this is the message i get when i do a this command : strongswan up blink-zin
initiating Main Mode IKE_SA blink-zin[1] to 41.220.79.242 generating ID_PROT request 0 [ SA V V V V ] sending packet: from 178.79.179.231[500] to 41.220.79.242[500] (156 bytes) received packet: from 41.220.79.242[500] to 178.79.179.231[500] (128 bytes) parsed ID_PROT response 0 [ SA V V ] received NAT-T (RFC 3947) vendor ID received FRAGMENTATION vendor ID generating ID_PROT request 0 [ KE No NAT-D NAT-D ] sending packet: from 178.79.179.231[500] to 41.220.79.242[500] (236 bytes) received packet: from 41.220.79.242[500] to 178.79.179.231[500] (296 bytes) parsed ID_PROT response 0 [ KE No V V V V NAT-D NAT-D ] received Cisco Unity vendor ID received XAuth vendor ID received unknown vendor ID: 93:cb:e6:09:86:13:39:46:a6:39:b1:c2:9c:09:45:6a received unknown vendor ID: 1f:07:f7:0e:aa:65:14:d3:b0:fa:96:54:2a:50:01:00 faking NAT situation to enforce UDP encapsulation generating ID_PROT request 0 [ ID HASH ] sending packet: from 178.79.179.231[4500] to 41.220.79.242[4500] (76 bytes) received packet: from 41.220.79.242[4500] to 178.79.179.231[4500] (92 bytes) parsed ID_PROT response 0 [ ID HASH V ] received DPD vendor ID IDir '41.220.79.242' does not match to 'blink' deleting IKE_SA blink-zin[1] between 178.79.179.231[zin]...41.220.79.242[%any] sending DELETE for IKE_SA blink-zin[1] generating INFORMATIONAL_V1 request 2460039461 [ HASH D ] sending packet: from 178.79.179.231[4500] to 41.220.79.242[4500] (92 bytes) connection 'blink-zin' established successfully
tail /var/log/secure May 21 13:15:24 credit charon: 14[IKE] deleting IKE_SA blink-zin[1] between 178.79.179.231[zin]...41.220.79.242[%any] May 21 13:16:03 credit charon: 10[IKE] initiating Main Mode IKE_SA blink-zin[2] to 41.220.79.242 May 21 13:16:03 credit charon: 04[IKE] deleting IKE_SA blink-zin[2] between 178.79.179.231[zin]...41.220.79.242[%any] May 21 13:20:18 credit ipsec_starter[16863]: charon stopped after 200 ms May 21 13:20:18 credit ipsec_starter[16863]: ipsec starter stopped May 21 13:20:21 credit ipsec_starter[16901]: Starting strongSwan 5.2.0 IPsec [starter]... May 21 13:20:21 credit ipsec_starter[16919]: charon (16920) started after 80 ms May 21 13:20:21 credit ipsec_starter[16919]: notifying watcher failed: Broken pipe May 21 13:20:48 credit charon: 11[IKE] initiating Main Mode IKE_SA blink-zin[1] to 41.220.79.242 May 21 13:20:49 credit charon: 13[IKE] deleting IKE_SA blink-zin[1] between 178.79.179.231[zin]...41.220.79.242[%any]
#7 Updated by Martin Willi over 10 years ago
rightid=@blink
IDir '41.220.79.242' does not match to 'blink'
Your peer authenticates itself as 41.220.79.242, so set your rightid to that (or omit the statement to default to right).
#8 Updated by kabir idris over 10 years ago
thanks Martin, however this is the new message
initiating Main Mode IKE_SA blink-zin[1] to 41.220.79.242 generating ID_PROT request 0 [ SA V V V V ] sending packet: from 178.79.179.231[500] to 41.220.79.242[500] (156 bytes) received packet: from 41.220.79.242[500] to 178.79.179.231[500] (128 bytes) parsed ID_PROT response 0 [ SA V V ] received NAT-T (RFC 3947) vendor ID received FRAGMENTATION vendor ID generating ID_PROT request 0 [ KE No NAT-D NAT-D ] sending packet: from 178.79.179.231[500] to 41.220.79.242[500] (236 bytes) received packet: from 41.220.79.242[500] to 178.79.179.231[500] (296 bytes) parsed ID_PROT response 0 [ KE No V V V V NAT-D NAT-D ] received Cisco Unity vendor ID received XAuth vendor ID received unknown vendor ID: d1:2c:c1:64:09:3a:6a:ff:ee:15:c9:e1:3b:f0:59:bf received unknown vendor ID: 1f:07:f7:0e:aa:65:14:d3:b0:fa:96:54:2a:50:01:00 faking NAT situation to enforce UDP encapsulation generating ID_PROT request 0 [ ID HASH ] sending packet: from 178.79.179.231[4500] to 41.220.79.242[4500] (76 bytes) received packet: from 41.220.79.242[4500] to 178.79.179.231[4500] (92 bytes) parsed ID_PROT response 0 [ ID HASH V ] received DPD vendor ID IKE_SA blink-zin[1] established between 178.79.179.231[zin]...41.220.79.242[41.220.79.242] scheduling reauthentication in 2564s maximum IKE_SA lifetime 3104s generating QUICK_MODE request 2971840146 [ HASH SA No KE ID ID ] sending packet: from 178.79.179.231[4500] to 41.220.79.242[4500] (316 bytes) received packet: from 41.220.79.242[4500] to 178.79.179.231[4500] (364 bytes) parsed INFORMATIONAL_V1 request 625736661 [ HASH N(INVAL_ID) ] received INVALID_ID_INFORMATION error notify establishing connection 'blink-zin' failed
#9 Updated by Tobias Brunner over 10 years ago
Looks like the values you configured in the left/rightsubnet and/or left/rightprotoport settings are incorrect (i.e. the traffic selectors, refer to ConnSection for details). For IKEv1 these have to match exactly on both ends. So you should discuss the correct settings with the other company.
#10 Updated by kabir idris over 10 years ago
Hi Tobias, It finally worked when i added
rightsourceip=10.42.42.0/24
However, only phase 1 is up, phase 2 is still down.
any idea on this ?
Thanks.
#11 Updated by Tobias Brunner over 10 years ago
rightsourciep is for the virtual IP functionality and makes no sense on initiators. But maybe you have to configure leftsourceip=%config (check with the company)? Then you should focus on why Quick Mode is not successful, which, according to the log you posted earlier, is because the traffic selectors don't match. You should ask the other company what addresses they expect to get tunneled (on both sides respectively) and then configure left|rightsubnet accordingly (and probably remove left|rightprotoport, unless traffic is really limited to UDP, but that has to be the case on both ends).
#12 Updated by kabir idris over 10 years ago
Hi, i have sent a mail to the company, however how do i know that the phase 2 is not working from my own server?
initiating Main Mode IKE_SA blink-zin[4] to 41.220.xx.xxx generating ID_PROT request 0 [ SA V V V V ] sending packet: from 178.79.xxx.xxx[500] to 41.220.xx.xxx[500] (156 bytes) received packet: from 41.220.xx.xxx[500] to 178.79.xxx.xxx[500] (128 bytes) parsed ID_PROT response 0 [ SA V V ] received NAT-T (RFC 3947) vendor ID received FRAGMENTATION vendor ID generating ID_PROT request 0 [ KE No NAT-D NAT-D ] sending packet: from 178.79.xxx.xxx[500] to 41.220.xx.xxx[500] (236 bytes) received packet: from 41.220.xx.xxx[500] to 178.79.xxx.xxx[500] (296 bytes) parsed ID_PROT response 0 [ KE No V V V V NAT-D NAT-D ] received Cisco Unity vendor ID received XAuth vendor ID received unknown vendor ID: c0:08:3a:77:04:f7:f9:1f:b9:96:63:cc:b7:53:76:fa received unknown vendor ID: 1f:07:f7:0e:aa:65:14:d3:b0:fa:96:54:2a:50:01:00 faking NAT situation to enforce UDP encapsulation generating ID_PROT request 0 [ ID HASH ] sending packet: from 178.79.xxx.xxx[4500] to 41.220.xx.xxx[4500] (76 bytes) received packet: from 41.220.xx.xxx[4500] to 178.79.xxx.xxx[4500] (92 bytes) parsed ID_PROT response 0 [ ID HASH V ] received DPD vendor ID IKE_SA blink-zin[4] established between 178.79.xxx.xxx[zin]...41.220.xx.xxx[41.220.xx.xxx] scheduling reauthentication in 2690s maximum IKE_SA lifetime 3230s received packet: from 41.220.xx.xxx[4500] to 178.79.xxx.xxx[4500] (92 bytes) parsed INFORMATIONAL_V1 request 2084770071 [ HASH N(DPD) ] generating INFORMATIONAL_V1 request 85708172 [ HASH N(DPD_ACK) ] sending packet: from 178.79.xxx.xxx[4500] to 41.220.xx.xxx[4500] (92 bytes) received packet: from 41.220.xx.xxx[4500] to 178.79.xxx.xxx[4500] (92 bytes) parsed INFORMATIONAL_V1 request 2547490959 [ HASH N(DPD) ] generating INFORMATIONAL_V1 request 3044163632 [ HASH N(DPD_ACK) ] sending packet: from 178.79.xxx.xxx[4500] to 41.220.xx.xxx[4500] (92 bytes) received packet: from 41.220.xx.xxx[4500] to 178.79.xxx.xxx[4500] (92 bytes) parsed INFORMATIONAL_V1 request 3319613308 [ HASH N(DPD) ] generating INFORMATIONAL_V1 request 545490185 [ HASH N(DPD_ACK) ] sending packet: from 178.79.xxx.xxx[4500] to 41.220.xx.xxx[4500] (92 bytes)
Thanks.
#13 Updated by kabir idris over 10 years ago
Hi Tobias, how do i know that the phase 2 is up from strongswan logs ?
Thanks.
#14 Updated by Tobias Brunner over 10 years ago
how do i know that the phase 2 is up from strongswan logs ?
You get a corresponding log message (CHILD_SA ... established with ...). Have a look at the IKEv1 examples.
#15 Updated by Tobias Brunner about 10 years ago
- Category set to configuration
- Status changed from Feedback to Closed
- Resolution set to No change required