[Openswan Users] Routing on a bigger network
paul at xelerance.com
Wed Feb 2 14:23:23 CET 2005
On Wed, 2 Feb 2005, Herbert Xu wrote:
> > 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
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)?
More information about the Users