<div>The feedback from Paul was very useful. But am looking at a very simple scenario without a DNS. I just need to enable setkey to "udp encapsulate packets" irrespective of the presence of a NAT in between. In the lab scenario where I am trying to implement, I just want two systems to be IPSec protected, but also UDP encapsulated. (Basically forcing it).
</div>
<div> </div>
<div>System1 Systen-2 </div>
<div>manually keyed ------IPSec proteced + udp encapsulated------------------manually keyed</div>
<div> </div>
<div>Is this already available in setkey ? if not is it possible to add ? </div>
<div> </div>
<div>It would be definitely helpful to get some expert opinions to start with. </div>
<div> </div>
<div>Is pluto also using the PFKEY interface with KLIPS ? </div>
<div> </div>
<div>many thanks and regards,</div>
<div>Pjothi<br> </div>
<div><span class="gmail_quote">On 2/28/06, <b class="gmail_sendername">Paul Wouters</b> <<a href="mailto:paul@xelerance.com">paul@xelerance.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">On Tue, 28 Feb 2006, Pjothi wrote:<br><br>> when I use pluto and in efffect KLIPS,<br>> NAT-T happens (although I have some problems, but for now it does work) and
<br>> packets are udp encapsulated.<br><br>So you applied the CONIFG_IPSEC_NAT_TRAVERSAL patch to the kernel. Good. Yes<br>that works.<br><br>> But, when I try to do the same with Racoon, when I enable NAT traversal with
<br>> racoon using Preshared keys, it says NAT-T support not compiled in. (I do<br>> see some nat-t parameters in sample racoon.conf but still it gives me this<br>> error)<br><br>NETKEY does support NAT-T, but it is located within its own code, and not in
<br>the more generic udp code like the KLIPS NAT-T patch. So NETKEY does support<br>NAT-T, but if you dont use that code (eg unload the modules), you also lose<br>the NAT-T support in general. This is why<br>1) KLIPS still needs a NAT-T patch
<br>2) The CONIFG_IPSEC_NAT_TRAVERSAL patch is independant of the KLIPS stack.<br><br>> I do not understand this behaviour, does this mean NETKEY IPsec<br>> implementation still does not support NAT-T or racoon still does not support
<br>> NAT-T.<br><br>I guess racoon and NETKEY are not aware nor compatible with their nat-t capabilities.<br><br>> Can anyone clarify this ? Because, atleast forcing UDP encapsulation is<br>> going to help me in a demo setup scenario where a SIP client and SIP proxy
<br>> can automatically setup SAD and SPD using setkey and bootstrap IPSec and<br>> protect themselves.<br><br>Did you ever look at Openswan's "Opportunistic Encryption"? That is exactly<br>what you are looking for. Automated key distribution via DNS(SEC) where one
<br>peer can have a key in the forward DNS (sip client behind nat) as long as<br>the other end (server/proxy) has a key in the forward. And autodetection<br>for establishing new tunnels on demand.<br><br>Though with NAT things are more complicated. See also the BTNS working
<br>group on anonymous IPsec channels with channel bindings.<br><br>Paul<br></blockquote></div><br>