<div>I collected the following information: </div>
<div> </div>
<div>NETKEY is a native IPSec implementation</div>
<div>Pluto is an IKE daemon for KLIPS IPSec implementation</div>
<div>rracoon is an IKE daemon for NETKEY part of KAME Project</div>
<div> </div>
<div>Here comes openswan related:</div>
<div> </div>
<div>openswan (2.4.0rc5) supports both NETKEY and KLIPS</div>
<div>racoon is part of ipsec-tools.(0.6.4)</div>
<div> </div>
<div>But I have the following problem:</div>
<div> </div>
<div>when I use pluto and in efffect KLIPS, </div>
<div>NAT-T happens (although I have some problems, but for now it does work) and packets are udp encapsulated.</div>
<div> </div>
<div>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)
</div>
<div> </div>
<div>I use Suse 10 (kernel 2.6.13)</div>
<div>openswan 2.4.0rc5</div>
<div>and ipsec-tools 0.6.4.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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. </div>
<div> </div>
<div>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.
</div>
<div> </div>
<div>many thanks for your time and hope to get some inputs.</div>
<div> </div>
<div>regards,</div>
<div>Pjothi</div>
<div><br> </div>
<div><span class="gmail_quote">On 2/28/06, <b class="gmail_sendername">VANHULLEBUS Yvan</b> <<a href="mailto:vanhu@free.fr">vanhu@free.fr</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">On Tue, Feb 28, 2006 at 02:25:40PM +0100, Francesco Peeters wrote:<br>> On Tue, February 28, 2006 14:05, Pjothi said:
<br>[NAT-T encapsulation in manual keying]<br>> I am not an OpenSwan programmer (I *am* a programmer, but not on OpenSwan,<br>> just to clear any misunderstandings before they occur <G>), but do know<br>> something about IPsec and IKE.
<br><br>I am not an OpenSwan developer/user, but I am an ipsec-tools (and also<br>a "non official" BSD IPSec stack) developer :-)<br><br><br>> NAT-T depends on encapsulating the IPsec traffic in UDP packets. Although
<br>> this could theoretically be done with manual keying, it is customarily<br>> connected to the IKE negotiations,<br><br>Yep.<br><br>> and usually uses the IKE port for<br>> encapsulation.<br><br>No. Using UDP port 500 was only done for first draft versions, latest
<br>versions and RFCs use a "port floating" to UDP 4500.<br><br><br>But it still needs NAT-T keepalives (done by racoon, I don't know if<br>this is done in kernel stack or userland for *Swan), and NAT-T has<br>really be done for IKE negociations, not static keying.
<br><br><br><br>Yvan.<br><br><br>-------------------------------------------------------<br>This SF.Net email is sponsored by xPML, a groundbreaking scripting language<br>that extends applications into web and mobile media. Attend the live webcast
<br>and join the prime developer group breaking into this new coding territory!<br><a href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
</a><br>_______________________________________________<br>Ipsec-tools-users mailing list<br><a href="mailto:Ipsec-tools-users@lists.sourceforge.net">Ipsec-tools-users@lists.sourceforge.net</a><br><a href="https://lists.sourceforge.net/lists/listinfo/ipsec-tools-users">
https://lists.sourceforge.net/lists/listinfo/ipsec-tools-users</a><br></blockquote></div><br>