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

[Pjothi]

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).

System1
Systen-2
manually keyed ------IPSec proteced + udp
encapsulated------------------manually keyed

Is this already available in setkey ? if not is it possible to add ?

It would be definitely helpful to get some expert opinions to start with.

Is pluto also using the PFKEY interface with KLIPS ?

many thanks and regards,
Pjothi

On 2/28/06, Paul Wouters <paul at xelerance.com> wrote:
>
> On Tue, 28 Feb 2006, Pjothi wrote:
>
> > 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.
>
> So you applied the CONIFG_IPSEC_NAT_TRAVERSAL patch to the kernel. Good.
> Yes
> that works.
>
> > 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)
>
> NETKEY does support NAT-T, but it is located within its own code, and not
> in
> the more generic udp code like the KLIPS NAT-T patch. So NETKEY does
> support
> NAT-T, but if you dont use that code (eg unload the modules), you also
> lose
> the NAT-T support in general. This is why
> 1) KLIPS still needs a NAT-T patch
> 2) The CONIFG_IPSEC_NAT_TRAVERSAL patch is independant of the KLIPS stack.
>
> > 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.
>
> I guess racoon and NETKEY are not aware nor compatible with their nat-t
> capabilities.
>
> > 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.
>
> Did you ever look at Openswan's "Opportunistic Encryption"? That is
> exactly
> what you are looking for. Automated key distribution via DNS(SEC) where
> one
> peer can have a key in the forward DNS (sip client behind nat) as long as
> the other end (server/proxy) has a key in the forward. And autodetection
> for establishing new tunnels on demand.
>
> Though with NAT things are more complicated. See also the BTNS working
> group on anonymous IPsec channels with channel bindings.
>
> Paul
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20060302/88798ebb/attachment.htm