<div dir="ltr"><div>Hi Paul,</div><div><br></div><div>Yes, I agree we don't want independent <b>(non-xfrmi</b>) connections up that can conflict</div>
about a range, and accidentally sent traffic from one tunnel to another unrelated tunnel. <div><br></div><div>Having agreed on that we also need to consider the route-based (xfrmi) connections which can have the same range i.e. <span style="color:rgb(80,0,80)">(</span>rightsubnet: <a href="http://0.0.0.0/0" rel="noreferrer" target="_blank">0.0.0.0/0</a><span style="color:rgb(80,0,80)"> -> leftsubnet: </span><a href="http://0.0.0.0/0" rel="noreferrer" target="_blank">0.0.0.0/0</a>) 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 <a href="http://0.0.0.0/0">0.0.0.0/0</a>. </div><div><br></div><div>P.S. Can you please let me know if you have any new insight or suggestion for working around the eroute in use issue. </div><div><br></div><div>Thank you,</div><div>-Rav Ya</div><div><br></div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 28, 2020 at 9:18 PM Paul Wouters <<a href="mailto:paul@nohats.ca">paul@nohats.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, 28 Apr 2020, Rav Ya wrote:<br>
<br>
> Setting all the connections to "overlapip=yes" did not help. I am still seeing the same “route<br>
> already in use” error.<br>
> Any other suggestions? or workaround that might work?<br>
<br>
No, then I think we need to look at it more to properly fix it.<br>
<br>
> If I understand correctly the next release (v3.32) will not have the legacy KLIPS and shall support<br>
> overlapping IPs. Is there a rollout date for the next release?<br>
> Also, if I build the master branch I should not see this issue. Right?<br>
<br>
git master has KLIPS removed, but the POLICY_OVERLAPIP code hasn't been<br>
removed yet. I have to have a look again at what needs to be changed<br>
to avoid the eroute in use issue. The problem is, we still don't want<br>
to have two independent (non-xfrmi) connections up that can conflict<br>
about a range, and accidentally sent traffic from one tunnel to another<br>
unrelated tunnel.<br>
<br>
Paul<br>
</blockquote></div></div></div>