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@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
[email protected]<mailto:[email protected]>
www.wepanow.com<http://www.wepanow.com>
________________________________
From: Izz Abdullah <[email protected]><mailto:[email protected]>
Sent: Wednesday, November 20, 2013 08:39
To: [email protected]<mailto:[email protected]>
<[email protected]><mailto:[email protected]>
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 <[email protected]><mailto:[email protected]>
Sent: Friday, November 15, 2013 08:42
To: [email protected]<mailto:[email protected]>
<[email protected]><mailto:[email protected]>
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:[email protected]]
________________________________
From: Izz Abdullah <[email protected]><mailto:[email protected]>
Sent: Friday, November 15, 2013 06:25
To: Martin Willi <[email protected]><mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>
<[email protected]><mailto:[email protected]>
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 <[email protected]><mailto:[email protected]>
Date: 11/15/2013 3:08 AM (GMT-06:00)
To: Izz Abdullah <[email protected]><mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>
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
[email protected]<mailto:[email protected]>
https://lists.strongswan.org/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]<mailto:[email protected]>
https://lists.strongswan.org/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]<mailto:[email protected]>
https://lists.strongswan.org/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
https://lists.strongswan.org/mailman/listinfo/users
