[Swan] XFRMi Interface route based IPSec with right=%any

[Rav Ya]

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 <paul at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20200429/10d6bd4f/attachment.html>