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

[Tobias Brunner]

Hi Oliver,

>> That's why the plugin does its own route lookup to
>> find the actual route and source IP to reach the other peer while
>> ignoring such source routes installed by the daemon.  As explained in my
>> last email this last part won't work without dumping the whole routing
>> table, unless the approach with marks is used.  The found source IP is
>> then finally forced on IKE packets using IP_PKTINFO.
> 
> I don't see how this requires us to dump the routing table given that:
> 
> 1) We know which routing table is ours (i.e. the one to exclude from lookups)
> 2) We are able to query the kernel for which tables are referenced.
> 3) We are able to query the kernel on a per-table basis.
> 4) The kernel will perform longest prefix matching for us.
> 
> Why can't we ascertain which routing tables are actually referenced within 
> policy routing (aka ip rule) and then successively query each specific table to 
> have the kernel tell us which nexthop we need rather than dumping the whole 
> thing and trying to do it ourselves.

Yes, that would be an alternative on kernels that are suitably
configured.  The current code evolved from a time where kernels commonly
did not support policy routing, and it still works on these, or if the
user decides not to use table 220 but to put the routes for virtual IPs
in the main routing table (via configure/strongswan.conf option).  In
these situations the only option we have is to dump the routes and
compare the listed source IPs with the virtual IPs.

Analyzing the routing rules would be an option, however, these could be
quite complex (not that our current code handles that any better as it
considers all routes, except for explicitly ignored tables).  But the
rules could probably serve as hint in which order to query the tables.

Still, I think the solution with the marks is even simpler as it
requires nearly no changes in the plugin and takes advantage of all the
kernel features and optimizations without having to add code that
manually queries individual tables.  What are your concerns regarding
that approach?  Or are you just questioning dumping the routing table in
general?  (I think we'll have to provide that fallback anyway, depending
on the configuration and the used kernel.)

> On a side-note, even with ~500k routes, I don't expect Strongswan to just be 
> (apparently endlessly) chewing up a whole CPU core and completely frozen, 
> which is exactly what it did. This is basically a self-induced DoS.

The code is not intended/optimized to handle that many routes.

>> The same is true if you don't use leftsourceip but, for instance, have a
>> host with two interfaces one in 10.0.1.0/24 and one attached to the
>> public Internet and you have a config like this:
>>
>> leftsubnet=10.0.1.0/24
>> rightsubnet=0.0.0.0/0
>>
>> In order for traffic generated on the gateway itself to get tunneled,
>> charon will also install a source route that forces the IP in the
>> 10.0.1.0/24 subnet installed on the internal interface as source IP for
>> all traffic.  As again, the source address would otherwise be the
>> physical IP and thus not match the IPsec policies with a source selector
>> of 10.0.1.0/24.  If that's unwanted the route installation can also be
>> disabled (charon.install_routes, however, this currently does not
>> disable dumping the routing table).
> 
> I don't think it's a valid assumption to assume that the IPsec node is 
> participating in 10.0.1.0/24 - that could easily be a routed prefix coming from 
> elsewhere.

A source route is only installed if the host has an IP address in the
configured subnet.

> But in any case, let's say that it is - We don't need to download
> the whole routing table in order to figure out what to add.

The problem is not the initial installation of the source route, but
finding a source IP to send IKE packets from afterwards, which that
route would interfere with as it maps the source address to the internal
IP (same as with the virtual IPs).

Regards,
Tobias