[strongSwan] Tunnel hung with Tasks queued: QUICK_MODE
Izz Abdullah
izz.abdullah at wepanow.com
Wed Nov 20 21:17:17 CET 2013
I thought I would try one more time. I really would appreciate any pointers. I went ahead and updated to 5.1.1 release thinking the DR4 release may not be completely supported.
Here is my ipsec statusall output:
[root at vpc2-ipsec-1-121 strongswan]# ipsec statusall
Status of IKE charon daemon (strongSwan 5.1.1, Linux 2.6.32-358.2.1.el6.x86_64, x86_64):
uptime: 2 minutes, since Nov 20 13:52:51 2013
malloc: sbrk 270336, mmap 0, used 201872, free 68464
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 10
loaded plugins: charon aes des rc2 sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem fips-prf gmp xcbc cmac hmac attr kernel-netlink resolve socket-default stroke updown xauth-generic
Listening IP addresses:
10.201.1.121
Connections:
dc-tunnel01: 10.201.1.121...204.77.193.133 IKEv1
dc-tunnel01: local: [aws] uses pre-shared key authentication
dc-tunnel01: remote: [dc] uses pre-shared key authentication
dc-tunnel01: child: 10.201.0.0/22 === 10.10.0.0/16 TUNNEL
school-tunnel02: 10.201.1.121...A.B.C.D IKEv1
school-tunnel02: local: [wepa] uses pre-shared key authentication
school-tunnel02: remote: [A.B.C.D] uses pre-shared key authentication
school-tunnel02: child: 10.201.0.0/16 === A.B.C.0/24 TUNNEL
school-tunnel03: 10.201.1.121...G.H.I.J IKEv1
school-tunnel03: local: [wepa] uses pre-shared key authentication
school-tunnel03: remote: [G.H.I.J] uses pre-shared key authentication
school-tunnel03: child: 10.201.0.0/22 === 172.27.7.0/24 TUNNEL
school-tunnel04: 10.201.1.121...L.M.N.O IKEv1
school-tunnel04: local: [wepa] uses pre-shared key authentication
school-tunnel04: remote: [L.M.N.O] uses pre-shared key authentication
school-tunnel04: child: 192.168.188.0/22 === 172.20.2.0/24 TUNNEL
Routed Connections:
dc-tunnel01{1}: ROUTED, TUNNEL
dc-tunnel01{1}: 10.201.0.0/22 === 10.10.0.0/16
Security Associations (4 up, 0 connecting):
dc-tunnel01[4]: ESTABLISHED 93 seconds ago, 10.201.1.121[aws]...204.77.193.133[gilbert]
dc-tunnel01[4]: IKEv1 SPIs: f130b99c344b2deb_i 948e983c6feb86e9_r*, pre-shared key reauthentication in 53 minutes
dc-tunnel01[4]: IKE proposal: 3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
dc-tunnel01{1}: INSTALLED, TUNNEL, ESP in UDP SPIs: c9c97a6b_i cf00946b_o
dc-tunnel01{1}: 3DES_CBC/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 12 minutes
dc-tunnel01{1}: 10.201.0.0/22 === 10.10.0.0/16
school-tunnel04[3]: ESTABLISHED 2 minutes ago, 10.201.1.121[wepa]...L.M.N.O[L.M.N.O]
school-tunnel04[3]: IKEv1 SPIs: e8d908dbebef71ee_i* 39ae2a7972d03430_r, pre-shared key reauthentication in 10 hours
school-tunnel04[3]: IKE proposal: 3DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024
school-tunnel04[3]: Tasks queued: QUICK_MODE
school-tunnel03[2]: ESTABLISHED 2 minutes ago, 10.201.1.121[wepa]...G.H.I.J[G.H.I.J]
school-tunnel03[2]: IKEv1 SPIs: 654a4f9d9ba643ae_i* 3a4d80763e673a4b_r, pre-shared key reauthentication in 10 hours
school-tunnel03[2]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
school-tunnel03{3}: INSTALLED, TUNNEL, ESP in UDP SPIs: cc7a6b43_i 55565a5f_o
school-tunnel03{3}: 3DES_CBC/HMAC_MD5_96, 13093 bytes_i (35 pkts, 3s ago), 4692 bytes_o (46 pkts, 3s ago), rekeying in 9 hours
school-tunnel03{3}: 10.201.0.0/22 === 172.27.7.0/24
school-tunnel02[1]: ESTABLISHED 2 minutes ago, 10.201.1.121[wepa]...A.B.C.D[A.B.C.D]
school-tunnel02[1]: IKEv1 SPIs: cd6dbc7050d3e0ad_i* 66bb99037e6279f7_r, rekeying disabled
school-tunnel02[1]: IKE proposal: 3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
school-tunnel02{2}: INSTALLED, TUNNEL, ESP in UDP SPIs: c60bb77f_i 2621b073_o
school-tunnel02{2}: 3DES_CBC/HMAC_SHA1_96, 13854 bytes_i (40 pkts, 17s ago), 3645 bytes_o (38 pkts, 17s ago), rekeying disabled
school-tunnel02{2}: 10.201.0.0/16 === A.B.C.0/24
As you can see, I am having issues with school-tunnel04. It gets stuck with "Tasks queued: QUICK_MODE". It doesn't progress any further.
Here are the relevant logs.
Nov 20 14:08:03 vpc2-ipsec-1-121 charon: 02[CFG] received stroke: initiate 'school-tunnel04'
Nov 20 14:08:03 vpc2-ipsec-1-121 charon: 08[IKE] initiating Main Mode IKE_SA school-tunnel04[6] to L.M.N.O
Nov 20 14:08:03 vpc2-ipsec-1-121 charon: 08[ENC] generating ID_PROT request 0 [ SA V V V V ]
Nov 20 14:08:03 vpc2-ipsec-1-121 charon: 08[NET] sending packet: from 10.201.1.121[500] to L.M.N.O[500] (152 bytes)
Nov 20 14:08:03 vpc2-ipsec-1-121 charon: 09[NET] received packet: from L.M.N.O[500] to 10.201.1.121[500] (120 bytes)
Nov 20 14:08:03 vpc2-ipsec-1-121 charon: 09[ENC] parsed ID_PROT response 0 [ SA V V ]
Nov 20 14:08:03 vpc2-ipsec-1-121 charon: 09[IKE] received draft-ietf-ipsec-nat-t-ike-03 vendor ID
Nov 20 14:08:03 vpc2-ipsec-1-121 charon: 09[IKE] received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
Nov 20 14:08:03 vpc2-ipsec-1-121 charon: 09[ENC] generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
Nov 20 14:08:03 vpc2-ipsec-1-121 charon: 09[NET] sending packet: from 10.201.1.121[500] to L.M.N.O[500] (236 bytes)
Nov 20 14:08:03 vpc2-ipsec-1-121 charon: 01[NET] received packet: from L.M.N.O[500] to 10.201.1.121[500] (296 bytes)
Nov 20 14:08:03 vpc2-ipsec-1-121 charon: 01[ENC] parsed ID_PROT response 0 [ KE No V V V V NAT-D NAT-D ]
Nov 20 14:08:03 vpc2-ipsec-1-121 charon: 01[IKE] received XAuth vendor ID
Nov 20 14:08:03 vpc2-ipsec-1-121 charon: 01[IKE] received DPD vendor ID
Nov 20 14:08:03 vpc2-ipsec-1-121 charon: 01[IKE] received Cisco Unity vendor ID
Nov 20 14:08:03 vpc2-ipsec-1-121 charon: 01[ENC] received unknown vendor ID: c5:f3:77:6f:47:9c:d8:9a:a2:0d:25:5e:45:32:54:e2
Nov 20 14:08:03 vpc2-ipsec-1-121 charon: 01[IKE] local host is behind NAT, sending keep alives
Nov 20 14:08:03 vpc2-ipsec-1-121 charon: 01[ENC] generating ID_PROT request 0 [ ID HASH ]
Nov 20 14:08:03 vpc2-ipsec-1-121 charon: 01[NET] sending packet: from 10.201.1.121[4500] to L.M.N.O[4500] (68 bytes)
Nov 20 14:08:03 vpc2-ipsec-1-121 charon: 16[NET] received packet: from L.M.N.O[4500] to 10.201.1.121[4500] (68 bytes)
Nov 20 14:08:03 vpc2-ipsec-1-121 charon: 16[ENC] parsed ID_PROT response 0 [ ID HASH ]
Nov 20 14:08:03 vpc2-ipsec-1-121 charon: 16[IKE] IKE_SA school-tunnel04[6] established between 10.201.1.121[wepa]...L.M.N.O[L.M.N.O]
Nov 20 14:08:03 vpc2-ipsec-1-121 charon: 16[IKE] scheduling reauthentication in 37340s
Nov 20 14:08:03 vpc2-ipsec-1-121 charon: 16[IKE] maximum IKE_SA lifetime 40940s
Nov 20 14:08:03 vpc2-ipsec-1-121 charon: 13[NET] received packet: from L.M.N.O[4500] to 10.201.1.121[4500] (84 bytes)
Nov 20 14:08:03 vpc2-ipsec-1-121 charon: 13[ENC] parsed INFORMATIONAL_V1 request 3028044190 [ HASH N(INITIAL_CONTACT) ]
Previously, it was stuck with the Tasks active: QUICK_MODE, until I added into the config leftsourceip=%config and leftmode=pushmode. The remote peer is a PIX which I have the config for if anyone would be so kind to assist me in getting this tunnel up.
Here is the relevant section of the ipsec.conf file:
conn school-tunnel04
type=tunnel
auto=start
keyexchange=ikev1
ikelifetime=12h
lifetime=11h
margintime=1h
rekeyfuzz=100%
authby=secret
ike=3des-md5-modp1024!
esp=3des-md5!
left=10.201.1.121
leftsourceip=%config
modeconfig=push
leftid=wepa
leftsubnet=192.168.188.0/22
leftfirewall=yes
right=L.M.N.O
rightid=L.M.N.O
rightsubnet=172.20.2.0/24
Since all of my other tunnels work and none of the others require NAT on both ends (remote and local), I am guessing my config is incorrect for setting up the NAT within strongswan. I need local to be 192.168.188.0/22 although the true private IPs are 10.201.0.0/16 and the remote to be 172.20.2.0/24 although it is 10.2.1.0/24. They are using an entire class A 10. subnet on their side, so I am having to create the NAT somewhere. We have a tunnel PIX <-> PIX, but this is for our DR site within Amazon AWS, and I need to get it transferred over ASAP to strongSwan.
I truly appreciate any assistance that you can be.
Sincerely,
Izz
Izz Abdullah
Senior Systems Engineer
Izz.Abdullah at wepanow.com<mailto:izz.abdullah at wepanow.com>
www.wepanow.com<http://www.wepanow.com>
________________________________
From: Izz Abdullah <izz.abdullah at wepanow.com><mailto:izz.abdullah at wepanow.com>
Sent: Wednesday, November 20, 2013 08:39
To: users at lists.strongswan.org<mailto:users at lists.strongswan.org> <users at lists.strongswan.org><mailto:users at lists.strongswan.org>
Subject: [strongSwan] Tunnel stuck in QUICK_MODE queued task
Any ideas? I made the changes as requested to the ipsec.conf for this particular connection by adding:
leftsourceip=%config
modeconfig=push
and that has changed the state a little, as shown below, but not it is just queuing QUICK_MODE and never completely establishes the tunnel.
Thanks again...
Izz Abdullah
Senior Systems Engineer
www.wepanow.com<http://www.wepanow.com>
________________________________
From: Izz Abdullah <izz.abdullah at wepanow.com><mailto:izz.abdullah at wepanow.com>
Sent: Friday, November 15, 2013 08:42
To: users at lists.strongswan.org<mailto:users at lists.strongswan.org> <users at lists.strongswan.org><mailto:users at lists.strongswan.org>
Subject: Re: [strongSwan] Tunnel stuck in QUICK_MODE active task
That made a difference. The tunnel is staying up, but after Phase1, it appears it never reaches phase2 now. Here are the logs now:
Nov 15 08:32:40 vpc2-ipsec-1-121 charon: 09[ENC] parsed ID_PROT response 0 [ ID HASH ]
Nov 15 08:32:40 vpc2-ipsec-1-121 charon: 09[IKE] IKE_SA school-tunnel04[5] established between 10.201.50.70[wepa]...W.X.Y.Z[W.X.Y.Z]
Nov 15 08:32:40 vpc2-ipsec-1-121 charon: 09[IKE] scheduling reauthentication in 37753s
Nov 15 08:32:40 vpc2-ipsec-1-121 charon: 09[IKE] maximum IKE_SA lifetime 41353s
Nov 15 08:32:40 vpc2-ipsec-1-121 charon: 09[NET] received packet: from W.X.Y.Z[4500] to 10.201.50.70[4500] (84 bytes)
Nov 15 08:32:40 vpc2-ipsec-1-121 charon: 09[ENC] parsed INFORMATIONAL_V1 request 2078815867 [ HASH N(INITIAL_CONTACT) ]
I may be wrong in my terminology of reaching phase 2, it is in ENC log where strongSwan parses out an INITIAL_CONTACT message from the PIX. Anyway, this is it. After this, only keep alives are sent back and forth. The tunnel never fully establishes and ipsec statusall has QUICK_MODE as queued:
school-tunnel04[5]: ESTABLISHED 4 minutes ago, 10.201.50.70[wepa]...W.X.Y.Z[W.X.Y.Z]
school-tunnel04[5]: IKEv1 SPIs: c3bb079f944f4a7d_i* b92d2bd072d03430_r, pre-shared key reauthentication in 10 hours
school-tunnel04[5]: IKE proposal: 3DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024
school-tunnel04[5]: Tasks queued: QUICK_MODE
I can bring the tunnel down with ipsec down school-tunnel04 now, instead of that queuing like before, but still no tunnel. I apologize for the n00b questions, but appreciate your assistance. I can't change the configuration of the PIX. It is one of our customers, and they have probably 20 VPNs and a lot of routing and NAT'ing within it. We have another VPN connection to them from our primary datacenter, but it is a PIX on this end. Since we are setting up our DR in Amazon AWS, I have opted to use strongSwan for all of our tunnels. For our other tunnels, I've very little issue and no issue to this affect in setting up the tunnel.
Thanks again,
Izz
Izz Abdullah
Senior Systems Engineer
www.wepanow.com<http://www.wepanow.com>
[cid:part1.04000301.05050706 at wepanow.com]
________________________________
From: Izz Abdullah <izz.abdullah at wepanow.com><mailto:izz.abdullah at wepanow.com>
Sent: Friday, November 15, 2013 06:25
To: Martin Willi <martin at strongswan.org><mailto:martin at strongswan.org>
Cc: users at lists.strongswan.org<mailto:users at lists.strongswan.org> <users at lists.strongswan.org><mailto:users at lists.strongswan.org>
Subject: Re: [strongSwan] Tunnel stuck in QUICK_MODE active task
Thanks for your reply Martin. I'll try this as soon as I reach the office and report back.
--
Izz
Sent using Android™
-------- Original message --------
From: Martin Willi <martin at strongswan.org><mailto:martin at strongswan.org>
Date: 11/15/2013 3:08 AM (GMT-06:00)
To: Izz Abdullah <izz.abdullah at wepanow.com><mailto:izz.abdullah at wepanow.com>
Cc: users at lists.strongswan.org<mailto:users at lists.strongswan.org>
Subject: Re: [strongSwan] Tunnel stuck in QUICK_MODE active task
Hi,
> 03[ENC] generating QUICK_MODE request 1871762211 [ HASH SA No ID ID ]
> 03[NET] sending packet: from 10.201.50.70[4500] to W.X.Y.Z[4500] (172 bytes)
> 14[NET] received packet: from W.X.Y.Z[4500] to 10.201.50.70[4500] (76 bytes)
> 14[IKE] queueing TRANSACTION request as tasks still active
The strongSwan initiator creates a Quick Mode, but the PIX does not
expect that. Instead, it seems that it wants to do a Mode Config
exchange in Push Mode first. Mode Config TRANSACTION exchanges always
have to complete before you can create any Quick Modes, hence the
configurations have to match on both sides.
We have support for push mode starting with 5.1.1. If you want to use a
Mode Config exchange (i.e. assign a virtual IP to the initiator), you
may try to set:
leftsourceip=%config
modeconfig=push
If you don't need any Mode Config, you may try to disable that on the
PIX.
Regards
Martin
_______________________________________________
Users mailing list
Users at lists.strongswan.org<mailto:Users at lists.strongswan.org>
https://lists.strongswan.org/mailman/listinfo/users
_______________________________________________
Users mailing list
Users at lists.strongswan.org<mailto:Users at lists.strongswan.org>
https://lists.strongswan.org/mailman/listinfo/users
_______________________________________________
Users mailing list
Users at lists.strongswan.org<mailto:Users at lists.strongswan.org>
https://lists.strongswan.org/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20131120/138da935/attachment.html>
More information about the Users
mailing list