On Thu, Dec 04, 2014 at 04:31:50PM -0500, Matt Rogers wrote: > On 11/30, Paul Wouters ? wrote: > > On Fri, 28 Nov 2014, Matt Rogers wrote: > > > > >>Matt wrote the problem below. I am still confused what exactly is > > >>happening and why we would need his patch for this. I would think > > >>that if we --down tunnelA we should notice the phase1 is still used > > >>by tunnelB and leave/move it around instead? > > >> > > > > > >The use of preferred_ike is really just to manually work around this cisco > > >quirk, > > >and it's kind of a corner case. What you described above may be a better > > >solution (it doesn't happen that way now) but in practice I don't know if > > >it would help avoid the cisco behavior like preferred_ike does. > > > > I don't think it is a corner case. It is a bug on our end. We have one > > parent that has two children and we delete one child. We shouldn't shoot > > the parent. > > > I've been hacking on this some and I believe I'm on the right path, but I'd > like > to post what I have so far and get some input. Unfortunately ipsec states > don't > keep track of their IKE state beyond their cloned-from state (which can go > away) > and newest_isakmp_sa (which won't get updated for the other host pair > instances > and tends to be #0, see the grepped status below). > > I have a "connswitch" test that I have not committed yet, that sets up the > test as:
can you commit test as a wip? I am curious to see what is going on. I need the same for IKEv2 and CREATE_CHILD_SA. Have you tried A and B with different authby or with xauth? say one with rsa and the other psk? > ... > 004 "TUNNEL-A" #1: STATE_MAIN_I4: ISAKMP SA established {auth=RSA_SIG > cipher=aes_256 integ=sha group=MODP2048} > 002 "TUNNEL-A" #2: initiating Quick Mode > RSASIG+ENCRYPT+TUNNEL+PFS+DONT_REKEY+UP+IKEV2_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW > 117 "TUNNEL-A" #2: STATE_QUICK_I1: initiate > 004 "TUNNEL-A" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode > {ESP=>0xESPESP <0xESPESP xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none > DPD=passive} > west # > ipsec auto --up TUNNEL-B > 002 "TUNNEL-B" #3: initiating Quick Mode > RSASIG+ENCRYPT+TUNNEL+PFS+DONT_REKEY+UP+IKEV2_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW > 117 "TUNNEL-B" #3: STATE_QUICK_I1: initiate > 004 "TUNNEL-B" #3: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode > {ESP=>0xESPESP <0xESPESP xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none > DPD=passive} > west # > ipsec auto --up TUNNEL-C > 002 "TUNNEL-C" #4: initiating Quick Mode > RSASIG+ENCRYPT+TUNNEL+PFS+DONT_REKEY+UP+IKEV2_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW > 117 "TUNNEL-C" #4: STATE_QUICK_I1: initiate > 004 "TUNNEL-C" #4: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode > {ESP=>0xESPESP <0xESPESP xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none > DPD=passive} > west # > > west # > ipsec auto --status | grep ISAKMP > 000 "TUNNEL-A": newest ISAKMP SA: #1; newest IPsec SA: #2; > 000 "TUNNEL-B": newest ISAKMP SA: #0; newest IPsec SA: #3; > 000 "TUNNEL-C": newest ISAKMP SA: #0; newest IPsec SA: #4; > 000 #1: "TUNNEL-A":500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_EXPIRE > in XXs; newest ISAKMP; lastdpd=-1s(seq in:0 out:0); idle; import:admin > initiate I am thinking why #0, why not #1? It probably need more thinking before one decide to stick parent state number in Quick mode Connection. I have ran into same issue in IKEv2. And not sure it is resolved. Curious to see test case. Also it may get tricky with rekey/re-authentication. -antony _______________________________________________ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev