On Wed, Apr 29, 2020 at 06:21:02PM +0200, Antony Antony wrote: > On Wed, Apr 29, 2020 at 10:44:36AM -0400, Paul Wouters wrote: > > On Wed, 29 Apr 2020, Antony Antony wrote:
> > Additionally, as I pointed out there is the issue of addresspool without > > narrowing=yes working in the Initial Exchanges, and the reason I did not > > push my patch yet was that we were still talking about whether having > > an addresspool should imply narroing or not. For rekey, this issue comes > > back. I assume your bestfit/scoring code also looks at the NARROWING > > policy to determine if only an exact match is allowed or a narrowed > > one is also allowed, so existing deployments with 3.30 or older that > > do not use narrowing=yes with an addresspool would break clients on rekey. > > I will check this one I guess testcase has responder narrowing yes. > If you have test case please point me. I don't think the patch I sent need narrowing yes on the responder for RW. I just checked with ikev2-child-rekey-09-windows - narrowing=yes It is a RW Windows test. 002 "road-east-x509-ipv4"[1] 192.1.2.23 #2: received INTERNAL_IP4_ADDRESS 192.0.2.100 test seems to work as expected without . Reasons to belived narrowing=yes is not aditional requirement this patch would add. May be I missed something! PLUTO_CONN_POLICY='RSASIG+ECDSA+ENCRYPT+TUNNEL+PFS+IKEV2_ALLOW+IKE_FRAG_ALLOW+ESN_NO+RSASIG_v1_5' An earlier version of the patch needed that then I relaized that whole logic different. And fixed it. _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
