strongSwan

That already happened before the patch
The route for ::/0 is in the main table. The route for ::1 is in the local table, as expected. No surprises here.

The route for ::/0 is in the main table. The route for ::1 is in the local table, as expected. No surprises here.

What do you mean? This is surprising, because, as I mentioned, the local routing table is explicitly ignored: source:src/libcharon/plugins/kernel_netlink/kernel_netlink_net.c#L2275 (that's the code without the patch from #2554). And this also works on my system.

So why would the ::1 route be enumerated on your system? What routing table (numeric value in rtm_table) is associated with that ::1 route? Could you also add the output of ip -6 route list table all and the contents of /etc/iproute2/rt_tables?

ip -6 r show table all

local ::1 dev lo proto kernel metric 256 pref medium
2a02:8071:9288:7d00::/64 dev br0 proto kernel metric 256 expires 7151sec pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev green-vlan proto kernel metric 256 pref medium
fe80::/64 dev br-green-vlan proto kernel metric 256 pref medium
fe80::/64 dev br0 proto kernel metric 256 pref medium
default via fe80::a96:d7ff:fe85:e002 dev br0 proto ra metric 1024 expires 1751sec mtu 1500 hoplimit 255 pref medium
local ::1 dev lo table local proto kernel metric 0 pref medium
local 2a02:8071:9288:7d00:468a:5bff:fe60:b202 dev br0 table local proto kernel metric 0 pref medium
local 2a02:8071:9288:7d00:6db8:cf7a:2ebc:ddc dev br0 table local proto kernel metric 0 pref medium
local fe80::468a:5bff:fe60:b202 dev green-vlan table local proto kernel metric 0 pref medium
local fe80::468a:5bff:fe60:b202 dev eth0 table local proto kernel metric 0 pref medium
local fe80::468a:5bff:fe60:b202 dev br-green-vlan table local proto kernel metric 0 pref medium
local fe80::468a:5bff:fe60:b202 dev br0 table local proto kernel metric 0 pref medium
ff00::/8 dev eth0 table local metric 256 pref medium
ff00::/8 dev green-vlan table local metric 256 pref medium
ff00::/8 dev br-green-vlan table local metric 256 pref medium
ff00::/8 dev br0 table local metric 256 pref medium

/etc/iproute2/rt_tables

#
# reserved values
#
255     local
254     main
253     default
0       unspec
#
# local
#
#1      inr.ruhep

local ::1 dev lo table local proto kernel metric 0 pref medium

That's the route to ::1 in the local table, which I have too on my system. However, you also have this route

local ::1 dev lo proto kernel metric 256 pref medium

that does not list a table, which, I think, means it is in the main routing table (that's when iproute2 does not list a table). Not sure what this route is exactly and why I don't see one (maybe depends on the kernel version). Anyway, I think we might be able to identify them by using rtm_type. I pushed a possible fix to the 2554-local-lan-gateway branch.

The two routes are in the local table:
ip -6 r show table local

local ::1 dev lo proto kernel metric 256 pref medium
local ::1 dev lo proto kernel metric 0 pref medium
local 2a02:8071:9288:7d00:468a:5bff:fe60:b202 dev br0 proto kernel metric 0 pref medium
local 2a02:8071:9288:7d00:6db8:cf7a:2ebc:ddc dev br0 proto kernel metric 0 pref medium
local fe80::468a:5bff:fe60:b202 dev green-vlan proto kernel metric 0 pref medium
local fe80::468a:5bff:fe60:b202 dev eth0 proto kernel metric 0 pref medium
local fe80::468a:5bff:fe60:b202 dev br-green-vlan proto kernel metric 0 pref medium
local fe80::468a:5bff:fe60:b202 dev br0 proto kernel metric 0 pref medium
ff00::/8 dev eth0 metric 256 pref medium
ff00::/8 dev green-vlan metric 256 pref medium
ff00::/8 dev br-green-vlan metric 256 pref medium
ff00::/8 dev br0 metric 256 pref medium

It might be just some buggyness with the kernel. It's version 4.15.5 with the ck patch set.

I tested the patches and they work fine.

The two routes are in the local table:

I'm not sure if that's true. For IPv6, iproute2 might also list routes from the main table with RTN_LOCAL if the local table is requested (and filter them explicitly if the main table is requested, which is the default), see here. This code is for compatibility with older kernels (that apparently didn't have multiple routing tables for IPv6) and depends on the static ip6_multiple_tables flag, which is set if a route in a table != main is returned by the kernel. According to the commit message, the assumption was that the kernel sends the routes from the local table first (with rtm_table set to RT_TABLE_LOCAL, thus setting the flag). But that might not be the case on current kernels. At least on the ones I tried, the first routes dumped by the kernel are from the main table.

And as I mentioned, if you list all tables (filter.tb set to 0), the "table ..." part is omitted only for routes from the main table (see here). So I really think that route is in the main table.

It might be just some buggyness with the kernel. It's version 4.15.5 with the ck patch set.

I checked with 4.14.16 in our testing environment and I see such a route too. I don't see it with 4.13, so probably is caused by a change in 4.14.

I tested the patches and they work fine.

OK, I'll push them to master soon.