[strongSwan-dev] [PATCH] Fix unnecessary dumping of entire routing table.

[Tobias Brunner]

Hi Oliver,

> Upon attaching to the errant thread I discovered it was happening within the
> get_route() code for libhydra's netlink plugin. I then noticed that the code
> for triggering a full dump of the routing table looked very wrong and was
> certainly incongruous with the comment directly below it.

It's not wrong.  The whole point of this function is to find a source
address for the daemon to reach the other peer (or a nexthop when
installing routes for IPsec tunnels).  The problem is that if, for
example, a virtual IP is used with rightsubnet=0.0.0.0/0 there will be a
default route in routing table 220 that forces that virtual IP as source
IP for all traffic so packets will match the installed IPsec policies.
Now for the IKE daemon we obviously don't want to use the virtual IP as
source address as that would send IKE traffic through the tunnel.
However, a lookup with RTM_GETROUTE without NLM_F_DUMP will just return
the default route in table 220.  There is no option to tell the kernel
to ignore routes in only that table (except, see below).  So we get all
routes and ignore routes from routing table 220 or if the set source IP
is a virtual IP (e.g. if the routes are not installed in a separate
routing table).  We always do that for IPv4, but for IPv6 on older
kernels, i.e. without support for the RTA_PREFSRC attribute, we can only
ignore these routes if they are installed in a separate routing table as
the routes won't have the virtual IP set (which means virtual IPs won't
work anyway for IPv6 on such systems).

> I also note commit 6bd1216e7a8a41eb6c103c27a05f50871e1aef99 which appears to
> have wanted to fix the issue without actually fixing it.

No, this commit added a workaround for the whole route lookup using
marks.  This avoids dumping the routing table altogether if the routing
rule that directs traffic to table 220 is inverted and has a mark set
(i.e. charon.plugins.kernel-netlink.fwmark = !<mark> is configured).
That way we can set that mark on the RTM_GETROUTE message and the kernel
will automatically ignore routes in routing table 220.  You should
definitely use this if you have a huge routing table.

Regards,
Tobias