[Ipsec-tools-users] Re: [Openswan Users] nat_traversal in manual keying ?

[Pjothi]

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.

regards,
Pjothi


On 2/28/06, VANHULLEBUS Yvan <vanhu at 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,
>
> Yep.
>
> > 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.
>
>
>
> Yvan.
>
>
> -------------------------------------------------------
> 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!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Ipsec-tools-users mailing list
> Ipsec-tools-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ipsec-tools-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20060228/a83c2229/attachment.htm