On 11/25, Paul Wouters ? 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. Matt > Paul > > Description of problem: > > When defining multiple connections to a single peer that differ in IPsec > SA options (peer subnet, etc), depending on the order that the > connections are associated with the host pair, the common IKE SA if > rekeyed by the peer can be associated to a connection different than the > one it started with. For example: > > conn base > left=192.168.1.2 > ... > > conn TUNNEL-A > also=base > right=192.168.1.10 > rightsubnet=10.0.1.0/24 > ... > > conn TUNNEL-B > also=base > right=192.168.1.10 > rightsubnet=10.0.2.0/24 > ... > > connections are added in this order: > TUNNEL-A > TUNNEL-B > > Left initiates with TUNNEL-A and then brings up TUNNEL-B. The IKE SA is > associated with TUNNEL-A. The peer now rekeys the IKE SA, and since > TUNNEL-B was the last connection to be associated with the host pair, it > is found first in the structure (connect_to_host_pair() is performed on > add and results in the last to be connected is the first seen in the > host pair list) . The new IKE SA is now under the TUNNEL-B connection. > > This switching is not normally a problem (this can happen pluto to pluto > with no ill effects). However, it has been observed that a Cisco ASA > peer may block IPsec traffic of the peer subnets for both the > switched-from and switched-to connections after the IKE SA is rekeyed > and deleted from the pluto end. So in the example above, if the intent > is to bring TUNNEL-A up temporarily, bring it down and leave TUNNEL-B > active, if TUNNEL-B catches the rekey and the operator deletes the new > IKE-SA, then the ASA will start to block both 10.0.1.0 and 10.0.2.0. If > the IKE SA manages to persist to the original connection then this > behavior isn't seen. > > So my proposed solution to work around this is the attached patch, which > adds a conn option of 'preferred_ike=yes|no" with the default of no. For > connections that have a common host pair, setting preferred_ike=yes on > one of them will allow that connection to take priority and respond to > the incoming IKE exchange. This only applies when there is no > discernable policy choice for the connection and overrides what would > normally be a pick of the first negotiable connection in the host pair > list. > > _______________________________________________ > Swan-dev mailing list > [email protected] > https://lists.libreswan.org/mailman/listinfo/swan-dev _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
