Hi Jiri, > Currently, negotiated traffic selectors are only applied on SPs. > Certain situations require them in SAs as well. > > Example (taken from a previously failig ipv6ready IKEv2.EN.I.1.1.7.1 test > case): > > ... > > This patch makes strongSwan set the negotiated TSs the SAs it creates. > > ... > > Does this look like the right thing to do? Why was this ever > limited to the BEET mode? Shouldn't the same thing be done for > TUNNEL mode as well?
Actually, in your example (and probably in all similar narrowing cases) the real problem is not that the traffic selectors are only applied to the policies, but that the same reqid is used for both policies. So what happens is that although the traffic selectors are correctly narrowed and installed, the IPsec SA and the new policy use the same reqid as the initial trap policy (which stays installed). So any traffic that matches the trap policy is now also handled by the IPsec SA (due to the reqid). Your patch does indeed fix the problem for this case, because the IPsec SA now no longer matches the packet that matched the trap policy, but I'm not sure whether that's the right way to go. The behavior in this test case is strange anyway, because when testing it, I get a new IPsec SA (all with the same reqid) for each packet that matches the trap policy but does not match the narrowed TS. Anyway, thanks for the patch and for bringing this issue to our attention, we will sure have a look into it. Regards, Tobias _______________________________________________ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users