[Openswan Users] steps to load KLIPS IPSec stack in 2.6.13 kernel

Paul Wouters paul at xelerance.com
Mon Mar 6 17:33:07 CET 2006


On Mon, 6 Mar 2006, Pjothi wrote:

> very much simplify this scenario, as a first step, I want to "manually key"
> with the main motivation to verify "UDP encapsulation". Then the next step
> would be to use SIP to establish assocations. So manual keying would be the
> first step for this. Already its possible with setkey to use manual keying,
> but I am not able to force it to UDP encapsulate the packets. But, with
> pluto using NETKEY IPSec stack, in automatic keying I am able to force NAT-T
> and in effect UDP encapsulation. But, I do not want IKE to be run and just
> want to force "UDP encapsulation" and the obvious choice is "manual keying".

No. "forcing" the udp encapsulation is just a trick within the IKE protocol,
so within the automatic keying protocol. We just "tell" the other site we
are NAT'ed, while we are not. This notifiaction message is part of IKE
autmatic keying, see RFC3947. You cannot send this IKE message in "manual
keying", therefor you cannot "force" it.

> As I googled and went through the archives for solving the above error, it
> was suggested to use KLIPS stack instead of NETKEY stack and this is the
> reason I wanted to move to KLIPS stack.

It won't matter what stack you use.

> So, I would like to know if NAT-T can be "forced" in manual keying with
> KLIPS IPSec stack and is it a good idea to do that, or this can be just done
> with the NETKEY IPSec stack itself and there is some possibility to solve
> the above error.

No you cannot. Yes it is a bad idea, because manually keyed connections never
get their key material updated, and all encryption happens on one key without
Perfect Forward Secrecy (PFS) support or anti-replay support.

Paul


More information about the Users mailing list