I collected the following information:
NETKEY is a native IPSec implementation
Pluto is an IKE daemon for KLIPS IPSec implementation
rracoon is an IKE daemon for NETKEY part of KAME Project
Here comes openswan related:
openswan (2.4.0rc5) supports both NETKEY and KLIPS
racoon is part of ipsec-tools.(0.6.4)
But I have the following problem:
when I use pluto and in efffect KLIPS, 
NAT-T happens (although I have some problems, but for now it does work) and packets are udp encapsulated.
But, when I try to do the same with Racoon, when I enable NAT traversal with racoon using Preshared keys, it says NAT-T support not compiled in. (I do see some nat-t parameters in sample racoon.conf but still it gives me this error)
I use Suse 10 (kernel 2.6.13)
openswan 2.4.0rc5
and ipsec-tools 0.6.4.
I do not understand this behaviour, does this mean NETKEY IPsec implementation still does not support NAT-T or racoon still does not support NAT-T.
So, here I wanted to see, if NETKEY implementation has NAT-T support, or atleast I wan't to force UDP encapsulation by manual keying.
Can anyone clarify this ? Because, atleast forcing UDP encapsulation is going to help me in a demo setup scenario where a SIP client and SIP proxy can automatically setup SAD and SPD using setkey and bootstrap IPSec and protect themselves.
many thanks for your time and hope to get some inputs.

On 2/28/06, VANHULLEBUS Yvan <vanhu@free.fr> wrote:
On Tue, Feb 28, 2006 at 02:25:40PM +0100, Francesco Peeters wrote:
> On Tue, February 28, 2006 14:05, Pjothi said:
[NAT-T encapsulation in manual keying]
> I am not an OpenSwan programmer (I *am* a programmer, but not on OpenSwan,
> just to clear any misunderstandings before they occur <G>), but do know
> something about IPsec and IKE.

I am not an OpenSwan developer/user, but I am an ipsec-tools (and also
a "non official" BSD IPSec stack) developer :-)

> NAT-T depends on encapsulating the IPsec traffic in UDP packets. Although
> this could theoretically be done with manual keying, it is customarily
> connected to the IKE negotiations,


> and usually uses the IKE port for
> encapsulation.

No. Using UDP port 500 was only done for first draft versions, latest
versions and RFCs use a "port floating" to UDP 4500.

But it still needs NAT-T keepalives (done by racoon, I don't know if
this is done in kernel stack or userland for *Swan), and NAT-T has
really be done for IKE negociations, not static keying.


This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
Ipsec-tools-users mailing list