[Openswan Users] Routing on a bigger network

[Paul Wouters]

On Wed, 2 Feb 2005, Herbert Xu wrote:

Hi Herbert,

> > No, it will be even harder, because KLIPS does (against RFC) longest-match
> > first, so you cna have policies for 10.0.0.0/16 and 10.0.0.0/24, and packets
> > for 10.0.0.3 will enter the latter tunnel instead of the former. NETKEY does
> > it based on the order of when you added the policies into the kernel.
> 
> This is not the complete story.  The native stack sorts policies using
> an arbitrary 32-bit integer.  This provides complete freedom to the user
> in determining the order of policies.
> 
> For example, Openswan's kernel_netlink.c implementation uses that integer
> to achieve exactly the same ordering as is used under KLIPS.

If that is the case, then why can someone use the classical hub-spokes
construction with KLIPS, but not with NETKEY?

eg: this works in KLIPS

connn one
	....
	rightsubnet=10.0.1.0/24

conn two
	....
	rightsubnet=10.0.0.0/8

conn three
	....
	rightsubnet=10.10.10.0/24

But as far as I understood and tries, this does not work in NETKEY, and
packets for 10.10.10.0/24 and 10.0.1.0/24 might end up going through conn two.

Did the behaviour in kernel_netlink or the kernel itself change to accomodate this?
If so, since when is that (roughly)?

Paul