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 _______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
