[Openswan Users] Routing on a bigger network

Paul Wouters paul at xelerance.com
Wed Feb 2 14:23:23 CET 2005

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 and, and packets
> > for 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

conn two

conn three

But as far as I understood and tries, this does not work in NETKEY, and
packets for and 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)?


More information about the Users mailing list