Hi Paul, Yes, I agree we don't want independent *(non-xfrmi*) connections up that can conflict about a range, and accidentally sent traffic from one tunnel to another unrelated tunnel.
Having agreed on that we also need to consider the route-based (xfrmi) connections which can have the same range i.e. (rightsubnet: 0.0.0.0/0 -> leftsubnet: 0.0.0.0/0) allow everything routed to the independent xfrmi interface. For the completeness, allow overlapping range across separate independent XFRMi even when the rigt/left subnet is not set for 0.0.0.0/0. P.S. Can you please let me know if you have any new insight or suggestion for working around the eroute in use issue. Thank you, -Rav Ya On Tue, Apr 28, 2020 at 9:18 PM Paul Wouters <p...@nohats.ca> wrote: > On Tue, 28 Apr 2020, Rav Ya wrote: > > > Setting all the connections to "overlapip=yes" did not help. I am still > seeing the same “route > > already in use” error. > > Any other suggestions? or workaround that might work? > > No, then I think we need to look at it more to properly fix it. > > > If I understand correctly the next release (v3.32) will not have the > legacy KLIPS and shall support > > overlapping IPs. Is there a rollout date for the next release? > > Also, if I build the master branch I should not see this issue. Right? > > git master has KLIPS removed, but the POLICY_OVERLAPIP code hasn't been > removed yet. I have to have a look again at what needs to be changed > to avoid the eroute in use issue. The problem is, we still don't want > to have two independent (non-xfrmi) connections up that can conflict > about a range, and accidentally sent traffic from one tunnel to another > unrelated tunnel. > > Paul >
_______________________________________________ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan
